If you have recommendations for improvements to the cache, please feel free to create a patch and we'll look at it (and probably apply it).
We're also looking at JBoss's new cache for CAS 3.5 (or at least upgrading the current version). If you're a JBoss Cache expert and want to help us out, let me know. Cheers, Scott On Wed, Feb 24, 2010 at 5:09 PM, Mihir Patel <[email protected]> wrote: > Hi, > > We are using CAS 3.3.5 with jboss cache 3.2.1 with MVCC locking. We have > JBoss Cache ticket registry cluster of two servers without session > replication on tomcat. Tickets are stored in jboss cache as attributes under > single node "ticket" which would create contention for read/write operations > as locking in JBoss Cache is done at the node level and not the attribute > level. We had REPEATABLE_READ isolation level with writeSkewCheck turned OFF > which would allow overrides without version check and creates inconsistent > number of tickets as well as missing tickets. > > Then, we turned on the writeSkewCheck ON and we started seeing exceptions > at the time of write operations complaining about trying to update older > version of the node "ticket", which was expected as MVCC versioning for > isolation level/transaction happens at node level. > > Considering the cache structure (the way tickets are stored) and > understanding the way jboss cache works, we decided to use less restricted > isolation level "READ_COMMITTED" which resolved the issue. We referred > http://community.jboss.org/wiki/JBossCacheMVCC to understand how > READ_COMMITTED and REPEATABLE_READ works with MVCC locking. > > Current structure is: > \ > \ticket = { TGT-1=TGT1, TGT-2=TGT2, ST-1=ST-1....} > > The structure which we think would allow us to use REPEATABLE_READ > isolation level is: > > \ > \ticket > \TGT-1=TGT-1 > \TGT-2=TGT-2 > \ST-1=ST-1 > \ST-2=ST-2 > > If we required we can also add two intermediate nodes for set of TGT and > ST, which would look something like: > > \ > \ticket > \TGT > \TGT-1=TGT-1 > \TGT-2=TGT-2 > \ST > \ST-1=ST-1 > \ST-2=ST-2 > > The way locking happens for isolation and transaction in jboss cache, > structure with tickets having their own nodes would result in a lot less > contention. > > Currently we haven't changed the structure and using whatever is default > with READ_COMMITTED isolation level. I just wanted to throw out the idea to > get other's opinion on the change. Any thoughts? > > Thanks, > Mihir > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
