Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JPA - Query isolation

 
Witold Marshal
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 553
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Witold Marshal
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks : )
 
Witold Marshal
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 553
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Database transactions are tied to the connection, not the user.
 
Witold Marshal
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks : )
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic