Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 18978 invoked from network); 9 Sep 2008 13:41:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Sep 2008 13:41:08 -0000 Received: (qmail 79894 invoked by uid 500); 9 Sep 2008 13:41:03 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 79876 invoked by uid 500); 9 Sep 2008 13:41:03 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 79865 invoked by uid 99); 9 Sep 2008 13:41:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Sep 2008 06:41:03 -0700 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Sep 2008 13:40:04 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Kd3SN-0000Dp-98 for derby-user@db.apache.org; Tue, 09 Sep 2008 06:40:35 -0700 Message-ID: <19392670.post@talk.nabble.com> Date: Tue, 9 Sep 2008 06:40:35 -0700 (PDT) From: derbyfan195 To: derby-user@db.apache.org Subject: Re: Does using DerbyDB require synchronization? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: huang195@gmail.com References: <19379460.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org Knut, Thanks for your response. I'm more interested in not having to establish separate connections for each thread as I've noticed establishing connection in Derby takes a while, so if I can use the same connection among the different threads (with some synchronization), that would be the ideal case for me at the moment. What puzzles me is that you said when you close a ResultSet on a connection, all other ResultSets lose their position. My understanding is that from a Connection, you get a Statement, and from a Statement, you get a ResultSet. Having multiple ResultSet from the same Statement is troublesome, but I thought ResultSets from different Statements should never have conflict with each other, i.e., if I close a ResultSet on Statement A, it shouldn't affect another ResultSet that's opened on Statement B. Is this understanding not correct? Looking forward to your reply. Thanks! - Hai Knut Anders Hatlen wrote: > > derbyfan195 writes: > >> Just started using Derby in my Java code and realized some weird >> synchronization issues. I have multiple threads accessing the same Derby >> Database (embedded one) through a single connection. They issue read-only >> queries, i.e., select, each with its own statement, and does some >> operations >> on the returned ResultSet using ResultSet.next() operation. However, I >> noticed sometimes, one of these next() calls would fail and gave me an >> error >> of next() is not permitted, make sure that AUTO_COMMIT is turned OFF. I >> don't know what this error means or why I need to turn AUTO_COMMIT off. >> Do I >> need any synchronization among the statement objects obtained from the >> same >> connection object? Any help would be appreciated. > > Hi, > > You can turn auto-commit off by calling conn.setAutoCommit(false). The > reason why it may help, is that with auto-commit on, the transaction > (Connection) is committed automatically each time a ResultSet is closed, > and when the transaction is committed, all ResultSets in that connection > lose their positions (and, depending on the holdability setting, they > may be closed). > > That said, whereas using the same connection concurrently from different > threads should work, I would recommend that you have a separate > connection for each thread. That would give you fewer problems with the > different threads changing the transaction state for each other, and it > could improve the performance since Derby could then execute more > queries in parallel. > > -- > Knut Anders > > -- View this message in context: http://www.nabble.com/Does-using-DerbyDB-require-synchronization--tp19379460p19392670.html Sent from the Apache Derby Users mailing list archive at Nabble.com.