8 Replies Latest reply on Jun 8, 2005 11:18 AM by Bela Ban

    LockInterceptor.transactions - why a synch List?



      As part of my performance analysis work I'm doing on my app that is using JBossCache, I've noticed some concurrency problems that appear to be related to the LockInterceptor.transactions attribute.

      While I haven't run tests on this to confirm, my analysis of LockInterceptor leads me to believe that a synchronized ArrayList may not be the best choice based on how it's used.

      First off, I think that a Set would suit the access pattern better than a list. As it stands, calls to transactions.contains() in invoke() will require a linear scan, similarly for transactions.remove() in afterCompletion().

      Secondly, I would suspect that some sort of reader/writer lock would be preferable to the single level of locking offered by Collections.synchronized.

      Although it doesn't seem that one would ever expect the number of entries in LockInterceptor.transactions to get very large, my tests on high-end (32 CPU) machines is indicating there is noticeable thread contention due to the time a thread has to spend doing linear scans of the list while holding an exclusive lock.

      Any thoughts you might have on this would be appreciated.