[Jdbm-general] RE: What is the default transaction mode for JDBM

[Jim A. <ji...@ex...>]

>
> Jim, I'm CC: to the JDBM list and quoting your entire message so that if
> there's someone interested, they'll step in.
>
I should probably subscribe to this list

> Jim Alateras wrote:
> >
> > This will be great Alex, do you have eviction policies set for
> the cache, do
> > you restrict the size etc. I can really make use of this to
> manage objects
> > across the transactions. One problem that I need to tackle is a
> better 'free
> > block list' structure. I was thinking of having a preconfigured
> number of
> > free block lists (i.e 8) which each house blocks of a specific size (64,
> > 128, 256 bytes etc) and a defrag thread to fragment
> neighbouring blocks into
> > larger blocks.  Is this something that is on your plans.
>
> The cache will initially have a configurable maximum number of objects.
> Cees suggested using soft refs when running under JDK 1.2+.  Otherwise,
> it will be a simple MRU cache based on a hashtable.
>

I guess it depends on what sort of control you want to enforce, should
probably make it adaptable (i.e. don't enforce an policy) and then Cees can
use his own if he doesn't care too much about what and when objects are
released and you could use a more controlled cache past on an LRU eviction
policy. (FYI There were discussions about cache on the castor-dev list and I
believe that someone actually developed several different forms of
caches..ask Arkin)

> I must admit I haven't even considered fragmentation yet.  So I really
> don't see why I should have plans to fix this... :) :)   Do you have
> evidence that we have a fragmentation problem?

That's cool. I haven't seen a problem either but looking at the code (and I
could be wrong) there is only one free list which gets scanned linearly
during the allocation process. Personally, I have found that a collection of
fixed sized free lists work better. Our usage pattern means that blocks are
allocated and freed at a relatively high frequency.
>
> > Tell me, about parallel overlapping transactions. The stuff in
> exolab core
> > allows for multiple overlapping transactions to occur on objects in the
> > database. It uses both pessimistic (lock up front) and
> optimistic (lock on
> > commit) locking. Does the JDBM currently support concurrent transactions
> > (disregarding locking issues).
>
> No, not directly.  JDBM does not manage/understand concurrent
> transactions.  Just like the stuff in exolab core, you can build you own
> "multi-transaction layer" on top of JDBM easily, though.  Essentially,
> the approach is to implement your own locking (optimist, pessimistic, or
> mixed) and a Transaction object which it used to hold your changes until
> you commit.
>
thanks, this at least provides me with a picture of where you want JDBM to
go. Thinks like locking and parallel  transaction support could be added
without making the code base much larger....but the aim is to have a small,
compact and fast database.

> Using this approach, you can do transaction grouping (at commit time)
> and have multiple non-conflicting transaction commit in the same
> RecordManager.commit(), which gives you a bit of a performance gain.
>
> It is my intention to continue in this direction after we're finished
> with JDBM version 1.0.  It might be part of a different "module" since
> Cees and I want to keep the JDBM basic package as simple and small as
> possible.
>
> We could definitly benefit from seeing your code... Commit at will :)
>

I am also in the process of developing an Admin tool, which is in the same
package jdbm.recman. The tool will dump lists and information about the
database so that we can analyse its usage


cheers
</jima>