This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Object Relational Mapping and the fly likes JPA - Query isolation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "JPA - Query isolation" Watch "JPA - Query isolation" New topic
Author

JPA - Query isolation

Witold Marshal
Ranch Hand

Joined: Feb 05, 2012
Posts: 48
I have question connected with Query features. May Query's results (for example some kind of Select order) contain some uncommited to the datebase records (or uncommitted updates)? Even if the datebase's isolation level is at least READ_COMMITTED?
Let's look at such situation: in scope of transaction I perform some updates to the database. I also create new entity and call persist() on it. Then I call a "select" Query to EntinityManger in this transaction. Quer has an ability to call flush() before it is performed (as I know) to ensure that the Query result is the most "up to date". The "flush()" method flushes all the changes to the datebase (including new persisted entity) but all writes to the datebas are made in uncommitted mode (as I know) and they will be committed at the end of transaction. But Query is called during that transaction so the changes are still uncomitted. What will be the result of that Query? Will it contain uncommitted changes made by "flush()" method? It seems that "yes" because that is why the autoFlush was introduced into Queries , but on the other hand it looks strange to get uncomitted changes from datebase as a result of Query.
So, how is it?
James Sutherland
Ranch Hand

Joined: Oct 01, 2007
Posts: 553
The concept of transaction means that one user/transaction will not see "another" user's/transaction's uncommitted data.

Of coarse you should see your own uncommitted data.


TopLink : EclipseLink : Book:Java Persistence : Blog:Java Persistence Performance
Witold Marshal
Ranch Hand

Joined: Feb 05, 2012
Posts: 48
Thanks : )
Witold Marshal
Ranch Hand

Joined: Feb 05, 2012
Posts: 48
One more question concernig that answer.
JPA entity connects to database using connection settings from persistence.xml where is defined user and password. So theoreticly each application client using such JPA entity logs to datebase on the same user account. How are they (application clients using the same JPA entities, similar (but another instance) EntityManger with the same logging settings ) treated by the underlying datebase (regarding previous question)? Are they treated as a one user and may see uncommitted updates made by each other or are they distinguished as separate users?
James Sutherland
Ranch Hand

Joined: Oct 01, 2007
Posts: 553
Database transactions are tied to the connection, not the user.
Witold Marshal
Ranch Hand

Joined: Feb 05, 2012
Posts: 48
Thanks : )
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JPA - Query isolation