[jboss-dev-forums] [Design of JBossCache] - Re: Should acquired locks be released in the order they were

Folks; This is a bit of a stale thread, but I do now have some data that confirms the change I proposed to TransactionEntry does indeed have a positive effect on scalability. My tests show it improves overall scalability by up to 6%. Some tests show no improvement, but none show degredation. Can everyone please re-review the proposal below as well as the earlier posts in this thread? If there are no objections, I'll make the change this week. anonymous wrote : | org.jboss.cache.TransactionEntry | - changed TransactionEntry.locks from List based implementation to | ConcurrentReaderHashMap. This avoids expensive linear scannng calls | to locks.contains() in addLock() and also improves concurrency by | avoiding blocking synchroized() calls where most of the access to | locks is read-only. I'm using ConcurrentReaderHashMap here more as | a Set than a Map since there is no value to store. We're really just | interested in efficient searches in locks and highly concurrent reads. | | - I'm not sure of the impact of this change on | org.jboss.cache.interceptors.OptimisticLockingInterceptor and | org.jboss.cache.interceptors.PessimisticLockInterceptor | which might be relying on some implementation specifics of the order of | insertion of entries into what getLocks() returns. Seems to me though | that if they do have some sort of dependency on ordering that there | should be a better way to deal with this... | | - this change impacts one public method - getLocks() which previously | returned a java.util.List and now returns a java.util.Set. Only one test | is affected by this (org.jboss.cache.cache.optimistic.OpLockingInterceptorTest) | which depends on List.get(int) method that isn't available in Set. | Thanks, Brian. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983518#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...