[jboss-dev] Embedded DB for internal use

[Brian Stansberry]

Forwarding a response from Elias Ross:

Elias Ross wrote:
 >
 > [I can't post to the dev list for some reason]
 >
 > I thought that the default configuration could use the JDBM cache
 > loader, which is a free DBM similar to BerkeleyDB. JDBM, like
 > Berkeley, uses the local file-system and doesn't have the overhead or
 > management complexity of a relational database. Unfortunately, I have
 > no idea what's going on with the ongoing development of the project.
 > It seemed to be going strong when I wrote the JdbmCacheLoader a year
 > and a half ago.

Yeah, my original hope was to use JdbmCacheLoader.  But the JDBM project 
seems pretty dead now; no release since mid-2005, something about a move 
to codehaus but no roadmap there on the codehaus site. We looked at it a 
bit this spring for 4.2 and rejected it as too inactive, and now several 
months have gone by and I see no sign of change.

 > Somebody from JBoss Cache could approach the current
 > authors and adopt the project, perhaps.
 >

Maybe that genman guy? ;)

Seriously though, I don't think the JBC guys have the bandwidth to drive 
JDBM.  I'd think adopting that would have to be a larger Red Hat 
commitment. Dunno one way or the other if there's any appetite for that.

Part of the reason I raised this topic is every now and then replacing 
HSQLDB with Derby gets tossed around.  If we were going to do that 
anyway, and we regard Derby as production quality, and some other 
internal use cases in the AS could benefit from having it available for 
internal use, then using it for cache overflow would make sense too.

 > I also wonder if some of the limitations with FileCacheLoader couldn't
 > be addressed, for example the way Microsoft worked around the 8.3
 > filename length limitations. And for transactions, keeping a
 > transaction log would be one way to address corruption. E.g. create
 > files using a ".tmp" designation, then do a rename in the commit
 > phase.

Whether we stick w/ FileCacheLoader for the session caches or not, 
improving FCL makes sense to me. JBC users are going to want to use it 
for the same reason AS did -- it's the most straightforward to setup and 
use, partic if you don't have a ton of control over the environment 
you're running in.

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com