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?
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?
Joined: Oct 01, 2007
Database transactions are tied to the connection, not the user.