Yes, it's in 3.2 and HEAD, although I need to port a small change to the HEAD version. I plan on making some changes tonight to have it look for the service=TreeCache cache.
FYI, I designed the sso assuming an unshared cache, and had been storing data in the cache in the following structure: /ABC12..../credentials --- credential data needed to support client authentication on another node for sso id ABC12... /ABC12.../sessions --- set of all the HttpSession id's associated with sso ABC12.... /XYZ98...../credentials /XYZ98...../sessions Ids for sso's are basically analogous to HttpSession ids. Since this data will now be in a shared cache, would you want all of the above under some sort of higher level structure, e.g. /sso/ABC12..../credentials ? If so, will that have performance implications due to locking -- e.g. while the /sso/XYZ98.../sessions node is being written, the /sso/ABC12.../credentials node is locked for read? Sorry, my knowledge of TreeCache locking is still limited :( The credentials and sessions were stored in separate nodes rather than as attributes of a single node because the sso manager needs to be able to respond to a rare situation where the credential node is updated after it is created. I implement that using TreeCacheListener.nodeUpdated(), and in that method ignore the many changes to the "sessions" node. Brian View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3835783#3835783 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3835783 ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
