2 Replies Latest reply on Dec 20, 2007 5:14 AM by Sebastien Pennec

    Optimistic Locking

    Sebastien Pennec Newbie

      Hello,

      I read the documentation and didn't understand a part of it:


      For example, if a transaction calls cache.getRoot().getChild( Fqn.fromString("/a/b/c") ) , nodes a, b and c are copied from the main data tree and into the workspace. The data is versioned and all calls in the transaction work on the copy of the data rather than the actual data. When the transaction commits, its workspace is merged back into the underlying tree by matching versions. If there is a version mismatch - such as when the actual data tree has a higher version than the workspace, perhaps if another transaction were to access the same data, change it and commit before the first transaction can finish - the transaction throws a RollbackException when committing and the commit fails.


      Is TreeCache going to follow this behaviour even during read calls? In the case of a thread that reads a value, while another one is modifying that same value, does the reader thread get an Exception?

      The kind of bahaviour that I need is this:
      - All reads can get the value immediately
      - All writes must wait for another write to finish to get a lock
      - A read call that happens while a writer thread locks the data recieves the data that was in the cache before the lock. In other words, the data is visible to other thread only once the writer thread has committed.

      Would that be possible with Optimistic locking?

      Thanks for your help :-)

        • 1. Re: Optimistic Locking
          Manik Surtani Master

          What you need is MVCC which is in the pipelines.

          With O/L writers will not block readers, but there is the overhead of copying nodes into a workspace to maintain Repeatable_Read semantics.

          O/L will allow concurrent writes but this is not fail fast and the 2nd write will throw an exception at commit time when optimistic validation occurs.

          Reader threads don't go through the validation phase and a reader will not throw an exception if someone writes at the same time.

          • 2. Re: Optimistic Locking
            Sebastien Pennec Newbie

            Hi Manik,

            Thanks for the reply! :)

            You're right: it looks like MVCC is exactly what I need.

            So I'm looking forward to TreeCache 3.x! :)