5 Replies Latest reply on Jan 10, 2007 12:48 PM by Manik Surtani

    SELECT FOR UPDATE semantics

    Brian Stansberry Master

      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.