Re: [jbosscache-dev] Re: Session Clustering for SIP

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