Bit of a tangent on whether something like FCL belongs in JBC or in outside.
JBC rightly wants any CacheLoader impl it ships to be able to handle the
full spectrum of CacheLoader use cases. AIUI, this is the primary
objection to FCL -- it can't.
The AS session passivation needs a CL impl that only meets these
requirements:
1) No user intervention to set up (i.e. no creating tables for in Oracle
for JDBCCacheLoader)
2) Support passivation=true. No need for transactional writes.
3) Supports shared=false
4) Adding docs saying "if you want to put $JBOSS_HOME/server/all/data on
an NFS, we recommend a switch to JDBCCacheLoader" is not lovely but
acceptable.
So, conceptually there's a disconnect between JBC's requirements and the
AS's. Seems like thats one of the reasons a project provides a
pluggable API -- to let people who need one use a custom-tailored impl.
All this said, I'd *much* prefer a good solution that ships with JBC. :-)
Brian Stansberry wrote:
OK, if it doesn't belong in the AS, then JBC has to provide a
reliable
alternative, one that's not @Experimental and not
based-on-a-project-that's-last-release-was-1.0-in August-2005. :)
The AS need to reliably passivate sessions is real.
Bela Ban wrote:
> -1. I don't see what FCL has to do in the AS...
>
> Brian Stansberry wrote:
>> Manik Surtani wrote:
>>> What do you guys think? Too many people try and use this in
>>> production and then complain that it doesn't work. It is not
>>> transactional and cannot withstand a JVM crash midway during a write.
>>>
>>> Should we deprecate this in 2.2.0 and remove it in 3.0.0?
>>>
>>> I know that JBoss AS uses it in some cases, but can that not be
>>> changed to use the JDBM cache loader?
>>>
>>
>> No, it can't. :( Unfortunately, JDBM appears to be a pretty dead
>> project.
>>
>> FCL is just an impl of a pluggable interface though. If you don't
>> want it in 3.0 and if we can't find a valid replacement by the time
>> AS is ready to consume 3.0, then I can always pull the FCL code into
>> the AS/EJB3 source tree.
>>
>>> Cheers,
>>> --
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> manik(a)jboss.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com