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

[Brian Stansberry]

Manik Surtani wrote:
> 
> 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.
> 

OK.

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

Good point. Although IMHO we should just mention that paranthetically; I 
think 'good practice' would be to make them Serializable. Parantheticallly =

"(By default JBoss Cache uses JBoss Serialization, which is able to 
serialize classes that don't implement Serializable. So, the requirement 
to implement Serializable is not strictly required, but is good practice.)"

>> 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?  :-)

Sure, but after we make sure #3 is true.  I wrote that assuming all 
cache loaders use the Fqn parameter passed to any read call to replace 
the persistent Fqn before passing back any object.

Oh, never mind -- except for in loadEntireState, the CacheLoader 
interface never passes back any object that includes an Fqn! Only the 
data map.

I'll add the javadoc.

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