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

    SELECT FOR UPDATE semantics

    brian.stansberry

      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.

        • 1. Re: SELECT FOR UPDATE semantics
          manik

          Is the options api the best/cleanest way to do this?

          Like you said, as it only applies to pessimistic locking, it does seem fairly straightforward to implement.

          Is there a JIRA task for this?

          • 2. Re: SELECT FOR UPDATE semantics
            brian.stansberry

             

            "manik.surtani@jboss.com" wrote:
            Is the options api the best/cleanest way to do this?


            Not sure about best. It perturbs things the least. The alternative I can think of would be to add a method to Cache. But then all the interceptors that check for "get" calls would have to have that method(s) added. And a target method would have to be added to CacheImpl. With the Option, everyone is blissfully unaware except for PessimisticLockInterceptor.

            Like you said, as it only applies to pessimistic locking, it does seem fairly straightforward to implement.


            Yeah, I took a look at the interceptor yesterday to check for any gotcha, and it took me about 10 mins to add it w/ a simple 3-4 statement if block. Didn't test at all though.

            Is there a JIRA task for this?


            No, I wanted to check on the forum first whether people thought the whole concept was off. If you think its a useful feature, I'll open one. Deciding exactly how to implement, timing, etc can come later.

            • 3. Re: SELECT FOR UPDATE semantics
              manik

               




              No, I wanted to check on the forum first whether people thought the whole concept was off. If you think its a useful feature, I'll open one. Deciding exactly how to implement, timing, etc can come later.



              Useful enough, I guess, given the requests we've had for it. I'd implement it as an option for now, and upgrade it to a full API feature in 2.2.0/3.0.0 timeframe if enough usage warrants it.

              Found a JIRA task for it though: JBCACHE-629

              • 4. Re: SELECT FOR UPDATE semantics
                brian.stansberry

                Geez, my search skills need a serious upgrade. :(

                • 5. Re: SELECT FOR UPDATE semantics
                  manik

                  Fixed in CVS HEAD, will be in BETA1.

                  See o.j.c.options.ForceWriteLockTest for usage details.