[jboss-dev-forums] [Design of JBossCache] - Re: New Locking Strategy Proposal for JBoss Cache

[manik.surtani@jboss.com]

"jason.greene at jboss.com" wrote : "galder.zamarreno at jboss.com" wrote : Manik, thanks for the wiki, it's clearer now :)
  |   | 
  |   | For curiosity, how would you enforce SERIALIZABLE? It's quite an edge case but I guess it's exclusively locking read operations and the rest as it is, correct?
  | 
  | Yes, essentially an exclusive FQN lock is acquired on all read operations. We also have the ability to skip the node copy on writes, since it's not needed.
  | 
  | I think everyone is more likely to use the forceWriteLock option on a read (AKA SELECT FOR UPDATE) with READ COMMITTED or REPEATABLE READ instead of SERIALIZABLE, since it allows you to selectively chose when and what you serialize access to. 

Either way, to keep the design clean and standardised, this could be encapsulated in a SerializableNode.  But the concept is essentially an exclusive lock even for reads.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068172#4068172

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068172