"jason.greene(a)jboss.com" wrote : "galder.zamarreno(a)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 :
Reply to the post :