You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Christiaan <ch...@hotmail.com> on 2008/10/08 11:33:15 UTC
NonTransactionalRead & Query Fetchplan
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?
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.
kind regards,
Christiaan
--
View this message in context: http://www.nabble.com/NonTransactionalRead---Query-Fetchplan-tp19875446p19875446.html
Sent from the JDO - Development mailing list archive at Nabble.com.
Re: NonTransactionalRead & Query Fetchplan
Posted by Christiaan <ch...@hotmail.com>.
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.
Re: NonTransactionalRead & Query Fetchplan
Posted by Craig L Russell <Cr...@Sun.COM>.
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?
Craig
>
>
> kind regards,
> Christiaan
>
>
> --
> View this message in context: http://www.nabble.com/NonTransactionalRead---Query-Fetchplan-tp19875446p19875446.html
> Sent from the JDO - Development mailing list archive at Nabble.com.
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!