Re: [jboss-dev] Embedded DB for internal use

Could we use Berkeley DB only for unit testing and not distribute it? Afaik, from http://www.oracle.com/technology/software/products/berkeley-db/htdocs/lic... "Oracle employs a dual licensing model that offers customers a choice of either our open source license or a commercial license. Our open source license is OSI-certified and permits use of Berkeley DB in open source projects or in applications that are not distributed to third parties. Our commercial license permits closed-source distribution of an application to third parties and provides business assurance." Galder Zamarreno wrote: > 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. >> >