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

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