From jdo-dev-return-7717-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Sat Oct 11 11:43:34 2008 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 77816 invoked from network); 11 Oct 2008 11:43:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Oct 2008 11:43:34 -0000 Received: (qmail 40734 invoked by uid 500); 11 Oct 2008 11:43:33 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 40722 invoked by uid 99); 11 Oct 2008 11:43:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Oct 2008 04:43:33 -0700 X-ASF-Spam-Status: No, hits=3.7 required=10.0 tests=DNS_FROM_OPENWHOIS,FORGED_HOTMAIL_RCVD2,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; Sat, 11 Oct 2008 11:42:28 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KocsC-0004ie-BY for jdo-dev@db.apache.org; Sat, 11 Oct 2008 04:43:04 -0700 Message-ID: <19931884.post@talk.nabble.com> Date: Sat, 11 Oct 2008 04:43:04 -0700 (PDT) From: Christiaan To: jdo-dev@db.apache.org Subject: Re: NonTransactionalRead & Query Fetchplan In-Reply-To: <20FDA91B-7649-4F6B-A7A1-DA03A97F7B18@SUN.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: christiaan_db@hotmail.com References: <19875446.post@talk.nabble.com> <20FDA91B-7649-4F6B-A7A1-DA03A97F7B18@SUN.com> X-Virus-Checked: Checked by ClamAV on apache.org Hi Christiaan, On Oct 8, 2008, at 2:33 AM, Christiaan wrote: > > Hi, > I have a question about the behaviour of Queries after a commit when > "NonTransactionalRead" is set to true. Should a Query behave like it > did > before the commit? More specifically, when defining a fetchsize in the > FetchPlan I would like to see that the Query is still honouring this > fetchsize after a commit is given. If I am not mistaken, this is not > explicitly described in the specification? Correct. The behavior of a Query when the Transaction associated with the PersistenceManager is closed is undefined. > > > The scenario I am working with is as such: > I have set NonTransactionRead=true and Multithreaded=true. I have 1 > pm, and > 2 threads. Thread 1 performs reads (executing queries with large > result set) > and Thread 2 performs writes. Now when I am iterating over a large > query in > Thread 1 and Thread 2 is doing a commit, I don't want this to affect > the > iterating over the query in Thread 1. I'd be open to putting the behavior into the specification. Can you propose a patch to the specification? I am not sure where to put it in the spec. Currently commit() is used where persistent objects transition states. Basically my proposal would be that the behaviour of the query should be unchanged by a commit(). For me this currently a portability issue, since our application depend on the fact that the query behaves the same. May be the following note to 14.3 Architecture of Query would be sufficient: "The behaviour of a query should not depend on transactional boundaries"? regards, Christiaan -- View this message in context: http://www.nabble.com/NonTransactionalRead---Query-Fetchplan-tp19875446p19931884.html Sent from the JDO - Development mailing list archive at Nabble.com.