[jbosscache-dev] Re: Session Clustering for SIP

Thu May 22 10:05:38 EDT 2008

It seems that in the FieldBasedClusteredSession class, the 
setJBossInternalAttribute method (which is called by setAttribute) put 
the object in the cache and then add Obervers to check for potentials 
changes in the attributes of the object and if so set the session as 
dirty so that on transaction commit it is replicated,

So I was thinking to do the same at cache level, when the put is done 
add the observers and jbosscache takes care of the changes in the object 
and replicate if needed on transaction commit.  But it seems that the 
Observers can only be added on an AOPized object, so I still wonder why 
this is needed to add those observers in the FieldBasedClusteredSession 
if the object is already AOPized and not let JbossCache handle the 
replication process automatically...?

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