On Sun, May 9, 2010 at 3:05 AM, Jan Kotek <opencoeli@...> 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.
|