[jboss-dev] Embedded DB for internal use

[Brian Stansberry]

Sorry; no e-mail for a couple days.

1) Re: Berkeley DB, yes we can use it for unit testing but not 
distribute it.  But, the AS needs to test the config we ship and we 
won't ship a Berkeley DB config, so this doesn't help.

2) Re: just using JDBCCacheLoader+DefaultDS and extending the current 
approach of telling users to point DefaultDS to a production db:  this 
doesn't work well for the session caching cache loaders.  The persistent 
store for these sessions is not meant to be shared; it's a 
per-AS-instance store.  So using a shared db for it would be wrong.

Galder Zamarreno wrote:
> 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.
>>>
>>
> 


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