[jbosscache-dev] Re: Session Clustering for SIP
Manik Surtani
manik at jboss.org
Thu May 22 11:08:41 EDT 2008
On 22 May 2008, at 15:07, Brian Stansberry wrote:
> 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.)
Ah ok, makes sense now. Yeah, I can see how this can be added as an
optional interceptor in JBC. Like you said, only makes sense with
transactions though.
Not sure how generally useful it is, but it seems simple enough to
implement and harmless enough if disabled by default.
> 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
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org
More information about the jbosscache-dev
mailing list