[jbosscache-dev] Re: Session Clustering for SIP
Manik Surtani
manik at jboss.org
Thu May 22 09:12:16 EDT 2008
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
More information about the jbosscache-dev
mailing list