2 Replies Latest reply on Jan 30, 2007 4:31 PM by genman

    JBCACHE-957 Discussion Thread

    brian.stansberry

      Discussions related to http://jira.jboss.com/jira/browse/JBCACHE-957 -- Allow per-node configuration of LockParentForChildInsertRemove.

      Elias Ross had a good suggestion on this:


      The Node itself keeps a NodeLock instance. Perhaps the specific choice of lock (read-write) could be delegated to the NodeLock itself?

      In particular, for the method:

      boolean acquire(Object caller, long timeout, NodeLock.LockType lock_type);

      it might make sense to replace the LockType parameter with an operation parameter? E.g.

      boolean acquire(Object caller, long timeout, NodeLock.Operation op);

      Then there needs to be some way to set the particular strategy per node. It's theoretically possible, but there needs to be a standard API to expose this. E.g.

      void setLockStrategy( ... );

      With this in mind, the NodeLock interface should get revisited in time for 2.0.



        • 1. Re: JBCACHE-957 Discussion Thread
          manik

          While this is an interesting idea, and will very cleanly encapsulate the decision around the type of lock acquired based on:

          1) Locking Scheme (opt or pess)
          2) Operation (readdata, writedata, deletedata, readchild, createchild, deletechild for PL, readIntoWorkspace, writeFromWorkspace for OL)
          3) State of the LockParentForChildInsertRemove param.

          I'm a bit concerned about getting this into 2.0.0.B1. If anything, this will be a B2 feature, but I am really concerned with feature creep in 2.0.0. Anyone has the spare cycles for this? :-)

          • 2. Re: JBCACHE-957 Discussion Thread
            genman

            I took a stab at the API, but I don't know well enough what to do with the 13-14 references to the old acquire calls.

            I uploaded my patch to the JIRA issue at the top.