[jboss-dev-forums] [Design of JBossCache] - SELECT FOR UPDATE semantics

[bstansberry@jboss.com]

I know I raised this issue somewhere before, but can't find it, so here we go again...

We're about to finalize the 2.x API; before we do, can we add something that provides semantics similar to SELECT FOR UPDATE, i.e. ability to do a read, but acquire a WL in the process?  As it is now, there is no clean way for a tx to read a node and then be confident it can subsequently write to that node.  It's possible for another tx to also get a RL on the node, which will prevent the first tx getting the needed WL.

This would be very helpful with http sessions that are shared between webapps, where I'd like to use a cache node to store the session, and use the node lock to prevent concurrent access to the session.  The natural flow is to do a read, and then *maybe* do a write later if the session data has changed.  The RL from the initial read doesn't provide a strong enough semantic.  To work around that I'd need to do some hack like doing a put() at the beginning w/ a dummy key/value pair.

I've seen other threads that raised similar requirements.

I think doing this should be pretty simple.  I believe it only applies to pessimistic locking.  If we implemented it as an Option (e.g setReadForUpdate(boolean)) it would only affect the pessimistic lock interceptor.  That interceptor would, on a get request, check the option and if present:

1) If the requested node does not exist, create it, like it does with a put.
2) Acquire a WL instead of a RL.

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

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