[manik]

"aditsu" wrote:
Hm.. I'm not sure how it's related, but it sounds very good.

I don't bother protecting/synchronizing the maps in a node when accessed via the XXDirect() calls as I assume that any locking happens on a higher level (see javadocs on NodeSPI). So clearly this higher-level sync wasn't working and hence the concurrent modification exceptions. And true enough, a bug in the PessimisticLockInterceptor was only acquiring read locks for remove(Fqn, Key) calls rather than write locks.

"aditsu" wrote:

I updated again from CVS; it seems to work now and doesn't do MapCopy anymore. The performance is still not really great, but it may not be JBC's fault. I'll keep profiling.

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?

[aditsu]

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.

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