"manik.surtani@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@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