[jbosscache-dev] Re: Session Clustering for SIP

[Brian Stansberry]

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