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 jboss.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
_______________________________________________
>>>> jbosscache-dev mailing list
>>>> jbosscache-dev lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
a>
>>>
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry redhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
a>
|