This thread disappeared from the forum last week -- I'm about to post a new message, so I thought I'd reconstruct the thread....
On 5/25/04 Brian Stansberry wrote: anonymous wrote : A while ago I added package o.j.web.tomcat.tc5.sso which uses a TreeCache to provide cross-cluster support for Tomcat's Single Sign On valve. Scott suggested that it would be good if the sso code could share a TreeCache with the JBossCacheManager that will be used for session replication. | | | I'm writing to be sure I'm on the same page with those of you working on the JBossCacheManager. | | | I've tweaked the sso code so it exposes an MBean attribute for its TreeCache, which at a minimum would allow the Tomcat5 MBean to set the tree cache to some shared object. However, I saw in the jboss-service-50.xml file in HEAD a reference to a shared tree-cache mbean "jboss.cache:service=TreeCache". This led me to a couple of questions: | | | 1) Is the use of "jboss.cache:service=TreeCache" still the plan? If so, I'll look at updating the sso code to try to find this tree cache service as its default behavior, only creating its own cache if it can't find the shared service. | | | 2) What is the planned configuration of "jboss.cache:service=TreeCache"? The tree cache used by the sso is configured for REPL_SYNC, with READ_COMMITTED transaction isolation. On 5/25/04 Ben Wang replied anonymous wrote : Hi, | | | The JBossCacheManager code was checked in by Bela. I plan to take over and finish it next month. As for the service name, yes, service=TreeCache has been a naming convention. So mostly likely, we will stick with it. | | | My guess is for state replication, REPL_SYNC and READ_COMMITTED will be used as well. | | | BTW, has your code been checked in yet? | | | -Ben On 5/26 Brian Stansberry replied: anonymous wrote : 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=3836916#3836916 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3836916 ------------------------------------------------------- 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
