[jbosscache-dev] Re: Cache Loaders and Non-String Fqns - Was: 2.0.0.BETA2

[Manik Surtani]

On 16 Mar 2007, at 15:21, Brian Stansberry wrote:

> Manik Surtani wrote:
>> On 15 Mar 2007, at 18:24, Brian Stansberry wrote:
>>> Manik Surtani wrote:
>>>> I think we're going to need to support non-String Fqns.  We're  
>>>> not going away from that anytime soon.  :S
>>>
>>> Good.  I'm not positive, but I think the only place non-String  
>>> Fqns are irreparably broken is with a preload call to a cache  
>>> loader.
>> Well, any config file element that uses Fqns.  Eviction policies,  
>> for example.  But that's a limitation on the config file, nothing  
>> else.
>
> We should think about improving handling this for configurations  
> built by a DI framework.
>
>>> With other cache loader calls, the real fqn is available as a  
>>> call parameter, so the string-based representation used for the  
>>> persistent store doesn't have to leave the cache loader.
>> Yeah, that can be worked around.  What do you reckon the best  
>> approach for "encoding" Fqns are, for CLs that only use Strings?
>> For each Fqn element, "Type:" + element.getClass() + ":value:" +  
>> element.toString() ?
>
> Not sure why what we do now isn't sufficient (confession - haven't  
> really looked).

Right now we just do a toString() which isn't enough.

"1".toString() and new Integer(1).toString() will point to the same  
node and that's incorrect.

>
>> Could barf with user objects that don't override toString() and  
>> you have object hash codes...
>>
>
> Yeah, if element.toString() doesn't provide a stable, unique id for  
> element, then element's type is not appropriate for use in an Fqn  
> with a cache loader.
>
> This is a bit complex, but can be summarized in a prominent doc  
> page (and javadoc) on Fqn:
>
> 1) If cache is LOCAL with no cache loader, any Object will do.
> 2) If cache is replicated with no cache loader, any Serializable  
> will do.

Not necessarily - with JBoss Serialization (2) is no longer an issue.

> 3) If a cache loader is used, for each type 'element' in the Fqn  
> element.toString() must provide a stable, unique id for element.  
> Default Object.toString() is no good; most (if not all)  
> java.lang.Number classes are fine. A toString() impl that lists the  
> class and the field name-value pairs for all the fields that go  
> into an equals() evaluation is good.
> 4) If a cache loader is used and you want to use preload, the type  
> must be String.

Apart from that, a good summary.  Feel like adding it to the Javadoc  
in HEAD?  :-)


--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani