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...) >>>>> 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(a)redhat.com _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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

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

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...) >>>>>>> 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(a)redhat.com >> _______________________________________________ >> jbosscache-dev mailing list >> jbosscache-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosscache-dev > -- > Manik Surtani > Lead, JBoss Cache > manik(a)jboss.org -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com