On Sun, May 9, 2010 at 3:05 AM, Jan Kotek <openco...@gmail.com> wrote: > Hi Elias, > > I have new snapshot http://jdbm2.googlecode.com/files/jdbm2-snapshot2.zip > I reduced GC trashing (no GC Overhead exceed errors anymore), > secondary Maps and custom serialization are now implemented. > Compared to JDBM 1.0 it is about 3x faster. Still needs samples and > documetation.
Sounds great! > Now I am looking at concurrency. JDBM locks everything on > StorageManagar, my work extends this locking even to BTree and HTrees > (secondary maps consistency). > You replaced locking with ReentrantReadWriteLock, would you please > tell me what were performance benefits? Did you ran into big troubles? The performance was about 30% better on reads on a dual core CPU. I don't recall writes being much better. Under load, it exhibited some bugs I wasn't fully able to uncover. Read operations do affect in-memory state, since there are a lot of changes to cached data during a read. I will e-mail you the changes I made, plus a test program. > I am also newly considering JTA XAResource support. It would be very > minimalistic support. JDBM would still support only single > transaction. > Method getXAResource() would simply block until other transaction is active. > When first transaction would be released, getXAResource() would stop > blocking and returned new instance. This wouldn't work that well, so I expect users wouldn't bother with this feature. Still, it sounds like a start. ------------------------------------------------------------------------------ _______________________________________________ Jdbm-developer mailing list Jdbm-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdbm-developer
