I can't find information about how JTA transaction cooperates (initiates?) internal datebase transaction, for example a transaction in MySQL datebase which is added to
JEE servers datebase tx resources. This lack of knolwedge triggers some questions qbout how Optimistic Lock works (is implemented).
I will try to submit the problem in three steps to make it more clear (it is a little bit complicated). Maybe somebody will see what I mean.
1. I' m not sure whether each time JTA transaction starts (for example in CMT EJB) and some operation are made on datebase resource (even without JPA interface, it may be just injected DataSource ) Transaction Manager opens an interenal transaction in that datebase resource (for example the native MySQL transaction). In other words how closely is JTA transaction mapped on real interanl datebase native transaction? This is the first question for the whole problem.
2. The first point (above) makes another doubt. Let's see such example: I have CMT stateless EJB with Container-Manged Entity Manager which uses my JPA class. The methods codes of that EJB are conducted in JTA container manged transacions. Persistence.xml settings of my JPA indicate my MySQL datebase. In one method of my EJB I call "find()" (or Select Query) to get entity object, then I make some state changes to that entity object (some fileds values) and then I "flush()" it to the datebase. As far as I know, in this moment ("flush()" call) the changes made to entity object are flushed to final datebase source (MySQL db) as an update of a record. But this update is made in scope of datebase native transaction so that if the JTA transaction in my EJB method rollbacks this update will be rollbacked as well. The quetion is (connected with first point) when that native datebase transaction starts?
A. Does it start on my first method call on Entity Manger (find(), or Query )?
or
B. Does it starts on "flush()" call?
It is important question because my MySQL datebase is run in Repeatable Read isolation as default. If its native transaction starts at "find()" (or Select Query) then chosen record are blocked for writing for other transactions (threads) for the whole that transaction. If "find()" was made as separate call (automatically commited) then untill "flush()" is called, other threads can modify my record.
3. And here we get to the Optimistic Lock. If my JPA class will use Optimistic Lock (implementing field marked with @Version annotation) and the internal, native datebase transaction starts as it is described in case "A" then, concering that my datebase uses Repeatable Read isolation, the Optimistic Lock is completely
useless because datebase isolation doesn't allow for modifying record which was previously read by another transaction. If native transaction starts as it is described in "B" point, then despite Repeatable Read isolation, Optimistic Lock is still
useful because the record can be changed by another transaction between reading it by first
thread (my EJB method) and calling "flush()" in that thread.
So the main quetsion is how JTA transaction cooperates with internal datebase transaction.
Sorry for troubling but solving this question will help me a lot.