[jbosscache-dev] Re: Session Clustering for SIP

[Jean Deruelle]

Hi Brian and all jbosscache team,

Yes this is what I meant having the same benefit as if my class was 
annotated with @org.jboss.cache.pojo.annotation.Replicable (or 
@org.jboss.cache.aop.AopMarker and 
@org.jboss.cache.aop.InstanceOfAopMarker. or 
@org.jboss.cache.aop.annotation.PojoCacheable and 
@org.jboss.cache.aop.annotation.InstanceOfPojoCacheable  ), maybe on 
SET_AND_GET too.

Thanks
Jean

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