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.