• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Devaka Cooray
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
Bartenders:
  • Carey Brown
  • Roland Mueller

JPA - Query isolation

 
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Ranch Hand
Posts: 553
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks : )
 
Witold Marshal
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks : )
 
I've never won anything before. Not even a tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic