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. 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
