[jboss-dev] Embedded DB for internal use

[Galder Zamarreno]

Afaik, Java 6 includes Derby, which might be a good or not so good idea, 
but gets around the necessity to have hypersonic any more. Has anyone 
tried this Derby version?

Personally, I see two sides of the story here:

+ On one side, we have the CLs (cache loader) that customers will be 
using with JDBC, whether FCL or JDBCCL...etc. We already have DefaultDS 
which by default points to HS. When it comes to support, we don't 
support it. Users need to change to a production ready database. Why 
can't we do the same for JBC? Pretty much every user/customer uses a 
production ready database for something.

My point is, we're gonna be better of in production if we make EJB3 
cache services point to JDBC databases rather than file systems. At 
least until we found a better default CL. Customers could easily 
encounter the same issues Brian did UT'ing.

+ On the other side, we have unit testing, which Brian has issues with 
too (long file paths...etc). FCL does not work well here, HS does not 
either. I suspect this is what Brian needs resolving.

Cheers,

Brian Stansberry wrote:
> 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.
> 

-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat