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.
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? 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. Regads, Jan On Thu, May 6, 2010 at 10:39 PM, Jan Kotek <openco...@gmail.com> wrote: > Hi, > > this way would not work, as transaction needs to be bound to RecordManager. > HTree may have secondary HTrees which depends on it, and their also > must be part of transaction. > > Best way to support multiple transaction would be to throw away > current PageStore and use more advanced from H2 Database. > But this way jar file size would grow to 500 KB > > My goal is really not another Berkley DB (java edition), but very simple > store. > Even with my improvements jar file size will be around 120 KB. > > Jan > > > On Thu, May 6, 2010 at 9:29 PM, Elias Ross <gen...@noderunner.net> wrote: >> On Thu, May 6, 2010 at 11:45 AM, Jan Kotek <openco...@gmail.com> wrote: >>> Hi, >>> >>> I am not sure extending transaction support and concurrency is way to go. >>> There is many solutions which already have this (Valdemord, HBase...). >>> I think JDBM should be kept as very simple basic storage. >>> In fact I would like to promote JDBM as 'persistent Map'. >> >> I was guessing the original focus of the project was to produce >> something similar to Berkeley DB: >> http://www.oracle.com/database/berkeley-db/index.html . Which is a >> pretty simple storage product, but does support JTA. >> >> Something as simple as this would be a huge improvement: >> >> 1. Create a new HTree (the transaction log) at the start of a transaction >> 2. All reads in the current TX would go to the transaction HTree, then >> to the master HTree. >> 3. Upon prepare, write prepare record. >> 4. Upon commit, lock the master HTree, copy all changes to the master >> HTree, delete log. >> >> I suppose this could be done under a separate project. Still, it'd be >> nice to have something integrated as with Berkeley DB. >> > ------------------------------------------------------------------------------ _______________________________________________ Jdbm-developer mailing list Jdbm-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdbm-developer
