Re: [jboss-dev] Embedded DB for internal use
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