[jbosscache-dev] Re: Session Clustering for SIP

[Brian Stansberry]

You don't detect changes. What SET_AND_NON_PRIMITIVE_GET does is analyze 
the return type of a read, and if it's not a String/primitive wrapper, 
it flags the value read as needing to be replicated at request end. In 
JBC terms, that means recording that the replication interceptor needs 
to do a put to the cluster for that key/value pair at transaction 
commit. (Without a transaction, the concept makes no sense.)

SET_AND_GET is the same concept, just skips the step of checking the 
return type; always replicates.

Note that I haven't thought through at all how much this would truly 
help the AS session replication; e.g. what other features depend on the 
way we currently handle it, what things it would break, etc.  But I 
think it's an interesting idea. :)

Manik Surtani wrote:
> I'm a little confused here.  How do you plan to make this generic enough 
> for JBC without using AOP?
> 
> With session clustering, Brian is in control of a Session object and can 
> add code to setAttribute/getAttribute to replace the session in the 
> cache and thus trigger a replication event.
> 
> I can't see how I can make this generic enough to detect changes in 
> arbitrary objects people may put in the cache without the use of some 
> form of bytecode manipulation.  Or am I missing something?  :-)
> 
> 
> On 22 May 2008, at 13:05, Brian Stansberry wrote:
> 
>> Copying to jbosscache-dev list. Jean, since you're doing caching work, 
>> suggest you subscribe to that list if you haven't already.
>>
>> I think your suggestion is definitely worth considering. If I 
>> understand you correctly, you're basically proposing something like 
>> adding a replication-trigger config to JBC, whereby with 
>> SET_AND_NON_PRIMITIVE_GET, JBC would track the type of any read and if 
>> not primitive, generate a cluster-wide write at transaction commit.
>>
>> Jean Deruelle wrote:
>>> Hi Brian,
>>> Thinking a bit more about this.
>>> You seems to have achieved in http sessions what is not possible to 
>>> do with Jboss cache natively and that is to me a drawback for Jboss 
>>> Cache ease of use.
>>> It is monitor automatically any changes to an object even if its 
>>> bytecode has not been enhanced by JBoss AOP...
>>> Do you think it would not be better to integrate your code into Jboss 
>>> Cache this could help us to have a cleaner code and benefit others ?
>>> Maybe with a note saying that it's less performing than if you 
>>> preprocess your classes with Jboss AOP (if my guess that it is less 
>>> performing is right...)
>>> wdyt ?
>>> Best regards
>>> Jean
>>> Brian Stansberry wrote:
>>>> Jean Deruelle wrote:
>>>>> Brian Stansberry wrote:
>>>>> <snip/>
>>>>>>
>>>>>>>>> As a first version, I intend to try to keep things as simple as 
>>>>>>>>> possible so my plan is "just" to store the complete SipSession 
>>>>>>>>> object I have into the cache and let TreeCacheAop do the job 
>>>>>>>>> when attributes are added/modified/removed to replicate to 
>>>>>>>>> other node(s).
>>>>>>>>>
>>>>>>>>> I was looking at the AttributeBasedClusteredSession 
>>>>>>>>> implementation and one thing I fail to understand is why it is 
>>>>>>>>> using a lot of transient map to handle session attributes (all 
>>>>>>>>> attibutes, only modified, only removed Maps) instead of letting 
>>>>>>>>> the Cache handling that for you ? Even for replication it seems 
>>>>>>>>> to be done by hand through the storeSession method of the 
>>>>>>>>> JbossCacheManager class and the SnapshotManager class ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> This mostly relates to not forcing the user to have to remember 
>>>>>>>> to call setAttribute if they modify an attribute:
>>>>>>>>
>>>>>>>> Set set = session.getAttribute("set");
>>>>>>>> set.add(someObject);
>>>>>>>> // oops, forgot to call setAttribute, updated set doesn't 
>>>>>>>> replicate!
>>>>>>>>
>>>>>>> I thought and still think this is not needed with TreeCacheAop in 
>>>>>>> doing putObject instead of put (see 
>>>>>>> http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/1.2.4.SP2/TreeCacheAop/en/html_single/index.html#api) 
>>>>>>>
>>>>>>> and it seems that it is already used for the 
>>>>>>> FieldBasedClusteredSession but that there is an overhead there of 
>>>>>>> creating observer for the pojo although the TreeCacheAop does the 
>>>>>>> exact same thing for you (at least that is my understanding of 
>>>>>>> TreeCacheAop as defined in the link above "Note that a user will 
>>>>>>> only need to issue this call once for each POJO (think of it as 
>>>>>>> attaching POJO to cache management). Once it is executed, 
>>>>>>> TreeCacheAop will assign an interceptor for the pojo instance and 
>>>>>>> its sub-objects." but I start to think that my assumption is 
>>>>>>> wrong here... can you confirm ?)
>>>>>>>
>>>>>>
>>>>>> To use putObject you have to use FieldBasedClusteredSession, and 
>>>>>> PojoCache (fka TreeCacheAop) can only add the interceptor, detect 
>>>>>> changes to the object etc. if the attribute's class has been 
>>>>>> bytecode enhanced by JBoss AOP.  Not a default solution, since 
>>>>>> most users will not take the steps needed to bytecode enhance 
>>>>>> their classes.
>>>>>>
>>>>>> If you use putObject and the object is not bytecode enhanced, 
>>>>>> PojoCache has no idea if you subsequently change the object. So 
>>>>>> you're back to the  issue of needing to deal with user forgetting 
>>>>>> to call setAttribute.
>>>>> Ok it's clearer now and it all makes sense :-)
>>>>> I guess even with JbossCache 2.x and Jboss 5.x we will need to deal 
>>>>> with the same thing then, right ?
>>>>>
>>>>
>>>> Yes.
>>>>
>>>>> I was wondering if one could leverage the jboss-web.xml with new 
>>>>> tags in it to state which are the classes he wants to be 
>>>>> replicated. (with potentially pattern macthing)
>>>>> On those classes, at load time, JbossAS would add automatically the 
>>>>> necessary Jboss cache annotation 
>>>>> (@org.jboss.cache.pojo.annotation.Replicable) through the javassist 
>>>>> library and the classes will be aspectized with load time weaving 
>>>>> and thus the full features of PojoCache could be used with no extra 
>>>>> code.
>>>>> But I guess the problem here is that it still add some burden on 
>>>>> the end developer to describe things in jboss-web.xml and that 
>>>>> could be error prone so not an ideal solution neither I guess
>>>>>
>>>>
>>>> If a user doesn't want to annotate their classes, they can deploy a 
>>>> jboss-aop.xml file to get the load time weaving. Adding the facility 
>>>> you describe in jboss-web.xml might make the syntax a bit easier, 
>>>> but it's doable now.
>>>>
>>>>
>>
>> -- 
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> brian.stansberry at redhat.com
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> 
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
> 
> 
> 
> 
> 
> 

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