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 (JIRA)" <ji...@apache.org> on 2009/02/18 13:11:04 UTC

[jira] Created: (JDO-624) Query behaviour independent of transactional boundaries

Query behaviour independent of transactional boundaries
-------------------------------------------------------

                 Key: JDO-624
                 URL: https://issues.apache.org/jira/browse/JDO-624
             Project: JDO
          Issue Type: Bug
    Affects Versions: JDO 2 maintenance release 2
            Reporter: Christiaan


(see also http://www.nabble.com/NonTransactionalRead---Query-Fetchplan-to19875446.html)
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.This behaviour 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. 

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"? 


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (JDO-624) Query behaviour independent of transactional boundaries

Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JDO-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675411#action_12675411 ] 

Craig Russell commented on JDO-624:
-----------------------------------

This request seems to affect several areas of the specification, including optimistic vs. datastore transaction, transaction isolation level, and for JDBC implementations of JDO, the handling of the JDBC connection and statement holdability across commit.

I think a bit more behavior needs to be specified than a note in 14.3. Could you please be more specific as to what the behavior should be?

> Query behaviour independent of transactional boundaries
> -------------------------------------------------------
>
>                 Key: JDO-624
>                 URL: https://issues.apache.org/jira/browse/JDO-624
>             Project: JDO
>          Issue Type: Bug
>    Affects Versions: JDO 2 maintenance release 2
>            Reporter: Christiaan
>
> (see also http://www.nabble.com/NonTransactionalRead---Query-Fetchplan-to19875446.html)
> 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.This behaviour 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. 
> 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"? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (JDO-624) Query behaviour independent of transactional boundaries

Posted by "Christiaan (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JDO-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675669#action_12675669 ] 

Christiaan commented on JDO-624:
--------------------------------

The request is basically that "things should not change", so I doubt whether I can be more specific about something that should not change. I would assume that if I set "NonTransactionalRead" to true (reading is not depending on transactions), and I execute a query to read objects, this reading would not be affected by a commit on another thread for the same pm.

However, 2 of 3 jdo implementations I tried so far changed the behaviour of the query, so I think it should get some attention in the spec. One simply closed the query, the other loaded all instances into memory and then closed the query. From an implementation point of view this probably can be solved by using ResultSet.HOLD_CURSORS_OVER_COMMIT or may be have separate connection for queries when NonTransactionalRead, but I am no jdo implementation expert. I am just describing this from a user point of view. Anyway, I will look at the spec to see if I can discover the areas which are affected by this, but I am hoping that someone with more indepth knowledge of the spec can help out here.


> Query behaviour independent of transactional boundaries
> -------------------------------------------------------
>
>                 Key: JDO-624
>                 URL: https://issues.apache.org/jira/browse/JDO-624
>             Project: JDO
>          Issue Type: Bug
>    Affects Versions: JDO 2 maintenance release 2
>            Reporter: Christiaan
>
> (see also http://www.nabble.com/NonTransactionalRead---Query-Fetchplan-to19875446.html)
> 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.This behaviour 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. 
> 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"? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.