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

[Alex B. <boi...@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.

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 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?

> 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.

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 :)

alex.

-- 
Alex Boisvert, XJ2EE Project Manager
Exoffice Technologies, Inc.  
http://www.exoffice.com
mailto:boi...@ex...