"manik.surtani(a)jboss.com" wrote : | I don't bother protecting/synchronizing the maps [...] as I assume that any locking happens on a higher level | Oh, I see. So it should work with the raw HashMap's then, since the locks take care of the synchronization. "manik.surtani(a)jboss.com" wrote : | Performance not great, in relation to 1.4.1? Or in an absolute sense? What's your setup, how is your cluster configured, do you use cache loaders, eviction? | In an absolute sense. Just trying to see how many transactions/s I can get, and where the bottleneck is. It's not bad actually. I'm running everything on localhost for now, with one cache instance; settings are: REPL_SYNC, READ_COMMITTED, DummyTransactionManagerLookup, no cache loader and no eviction. I'm manually preloading all the "working data" from a db and inserting into the cache, and then using a listener for writing back the changes in an async manner (in batches). There are lots of elements in the equation, JBC is just one of them. I have changed much of the app code along the way, it's actually not stressing JBC so much anymore (e.g. I used to have indexes stored in the cache but I moved them out). Btw, I should probably try stressing it again to verify that the bug is really fixed. My impression is that the cache is doing OK now; still, I'm doing some ugly stuff with it that could probably be improved, such as explicit locking/unlocking (across transactions) using "marker" nodes, avoiding deadlock-timeouts using random waits, and even using a listener instead of a cache loader. I mentioned them in other threads, and you already gave some suggestions & fixed bugs, I'll just have to try them out. Thanks Adrian View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069083#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...