On 2002.12.26 13:42:56 -0500 Alex Loubyansky wrote: > DJ> I don't understand how this works yet. I'd really appreciate a > detailed > DJ> explanation of what happens when 2 threads/transactions > simultaneously > DJ> access one entity. I'd like to know what state the jboss "entity > values" > DJ> are in and what state the database is in at all points of such an > DJ> interaction. > > Well, I'll try to explain. > Suppose, we use version column strategy, i.e. counter column that will > be increased by 1 after each update. > > Now, suppose, there are two concurrent clients running in each own tx > trying to modify some data in the same entity. > > When tx from the first client reaches the entity, i.e. when the first > client reads or modifies some data of the entity, JDBCOptimisticLock > locks the version field. That means it stores version field and > version value. It stores it in a TransactionLocal, similar to > ThreadLocal but keyed by tx. > Ok. Suppose the first client continues with its tx. > > Now comes the second client with its own tx. Again, when this tx > reaches the same entity, JDBCOptimisticLock does the same thing as it > did for the first tx, i.e locks version column and value and stores it > in TransactionLocal. > Note, that it deals with not modified by the first client version of the > entity. > At least, my tests show it. But I'd would appreciate others to try it. > > Then, suppose the second client stores the entity, before the first > client. The changes made by the second client are persisted and > version number is incremented. > > Then, the second client commits its changes. But as the version value > locked differs from the value in the db, it fails. > > Hope this one is better.
Thank you, that is very clear. Just to make sure I understand: I think this relies on the database transaction isolation level to be read committed or weaker? with repeatable read, snapshot (not a jdbc "official" level) or serializable, the update should fail due to the databases consistency strategy rather than checking rows changed in the update since the only value visible to the update in tx1 is its original version number. Is this correct? thanks again david jencks > > alex > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
