Ah, thanks Alex! Unfortunately, answering some questions lead to more questions for even better understanding ;-)
Using the Version Strategy as an example, if you have one app server talking to one database (equiv to commit-option B), will this make mostly-read transactions better or not make that much of a difference? Actually, now that I'm thinking about it, would someone help enlighten my dim LED with a simple layout about when this cool Optimistic-Locking would offer the best results, and when it is not (I assume highly-volatile Tx entities would not, but assuming equals ass-u-me)? Single JBoss, Commit-Option A, D --Read only entities, mostly-read entities, and highly-volatile entities Single JBoss, Commit-Option B --Read only entities, mostly-read entities, and highly-volatile entities Multi-Jboss Cluster, Commit-Option C --Read only entities, mostly-read entities, and highly-volatile entities Gone through Dain's great JbossCMP pay-for docs, well worth it! 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
