[jbosscache-dev] Re: Session Clustering for SIP

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