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
