If we were going to do that anyway, and we regard Derby as production quality

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.

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