db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christiaan <christiaan...@hotmail.com>
Subject Re: NonTransactionalRead & Query Fetchplan
Date Sat, 11 Oct 2008 11:43:04 GMT



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.


Mime
View raw message