[jboss-dev] Embedded DB for internal use

[Galder Zamarreno]

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/licensing.html

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

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