2 Replies Latest reply on Feb 21, 2005 12:41 PM by Luis Daniel Benavides

    Optimistic Locking

    Luis Daniel Benavides Newbie

      Hi all!

      I am implementing a version of JBCache using optimistic loking, following the indications presented in the forum and in the docs i found in the distribution.

      So far I add:
      - an aspect to intercept the behavior of findNode(fqn)
      - I add an Interceptor to manage creation of nodes in the workspace when a put method is invoked.
      - I also add a call interceptor that avoids the chain of interceptors when i am in optimistic mode and i am not preparing or commiting.

      Now I have this questions:
      1. My first draft design attempt to update all the caches is the clusterm but the one performing the operation, this because prepare and commits avoid self :(. Any clues here?

      2. I am not sure if i have to add the nodes that i have to lock to the list of the transaction, so far i am only adding the operations. I hope this will work :(. Is this ok? the documentation talks that they are using for unloking/ abort, the other nodes need this list or they make their own list?

      3. This topic seems like dead in the forum..are you using other media to discuss this? a mail list?

      Any advice/critic will be apprecited !

      Daniel

        • 1. Re: Optimistic Locking
          Luis Daniel Benavides Newbie

          Just to follow track and in some one is interested!

          > Mr. Bela Ban
          >
          > Hi!
          >
          > I have posted this in the forum if you prefer to answer there.
          >
          > I am implementing a version of JBCache using optimistic locking,
          > following the indications presented in the forum and in the docs i found
          > in the distribution.
          >
          > So far I add:
          > - an aspect to intercept the behavior of findNode(fqn)
          > - I add an Interceptor to manage creation of nodes in the workspace when
          > a put method is invoked.
          > - I also add a call interceptor that avoids the chain of interceptors
          > when i am in optimistic mode and i am not preparing or commiting.



          Are you doing this on CVS head, or on 1.2 ?


          > Now I have this questions:
          > 1. My first draft design attempt to update all the caches is the cluster
          > but the one performing the operation, this because prepare and commits
          > avoid self :( . Any clues here?



          On TX commit ?

          > 2. I am not sure if i have to add the nodes that i have to lock to the
          > list of the transaction, so far i am only adding the operations. I hope
          > this will work :( . Is this ok? the documentation talks that they are
          > using for unloking/ abort, the other nodes need this list or they make
          > their own list?

          > Mr. Bela Ban
          >
          > Hi!
          >
          > I have posted this in the forum if you prefer to answer there.
          >
          > I am implementing a version of JBCache using optimistic locking,
          > following the indications presented in the forum and in the docs i found
          > in the distribution.
          >
          > So far I add:
          > - an aspect to intercept the behavior of findNode(fqn)
          > - I add an Interceptor to manage creation of nodes in the workspace when
          > a put method is invoked.
          > - I also add a call interceptor that avoids the chain of interceptors
          > when i am in optimistic mode and i am not preparing or commiting.



          Are you doing this on CVS head, or on 1.2 ?


          > Now I have this questions:
          > 1. My first draft design attempt to update all the caches is the cluster
          > but the one performing the operation, this because prepare and commits
          > avoid self :( . Any clues here?



          On TX commit ?

          > 2. I am not sure if i have to add the nodes that i have to lock to the
          > list of the transaction, so far i am only adding the operations. I hope
          > this will work :( . Is this ok? the documentation talks that they are
          > using for unloking/ abort, the other nodes need this list or they make
          > their own list?



          Don't know, this is your design decision

          > 3. This topic seems like dead in the forum..are you using other media to
          > discuss this? a mail list?



          No, the forum (JBossCache) is the right place.

          Do you have any design documents regarding this ?

          Don't know, this is your design decision

          > 3. This topic seems like dead in the forum..are you using other media to
          > discuss this? a mail list?



          No, the forum (JBossCache) is the right place.

          Do you have any design documents regarding this ?

          • 2. Re: Optimistic Locking
            Luis Daniel Benavides Newbie

            Hi !

            thanks for your answer !

            Are you doing this on CVS head, or on 1.2 ?

            I am using cvs head, It was hard to download the cvs file, are the sources included in the distribution? i download that version but there are no sources there!.

            > Now I have this questions:
            > 1. My first draft design attempt to update all the caches is the cluster
            > but the one performing the operation, this because prepare and commits
            > avoid self :( . Any clues here?


            you wrote: On TX commit ?

            Yes.

            My design idea is to intercept the calls before the chain and skip it if the process is taking place (active)*. When I go directly to the methods in cache, I have an aspect to intercept the calls to findNode(fqn), this aspect will answer with the version in the workspace.** Once the system try to prepare or commit i will use the system with out modification(using the chain).

            * I also check: if the node needs to be created in the work space(new node && put method), I modify the transaction table with CRUD opps.
            ** It will read a copy from the actual cache, if it does not have one!

            The problem is that as i have not modified my current cache, i should tell it to apply the transaction but the commit and prepare methods skip self.

            I am missing something here?


            you wrote: Do you have any design documents regarding this ?

            Not yet. I am doing my draft design . But so far i Have:

            Things to refactor in aspects:
            1. I destructively modify:
            - Node: I make it implements Versionable(my own interface).
            - Entry: I add a Map as a work space (ouch.. i said is a draft).
            - I modify cache to add my new interceptor.

            Aspects:
            - FindFqnAspect. To intercept calls when i am using optimistic locks.
            - NodeVersionAspect manage versioning, it has to know when to change a version and when not to do it.

            Regards
            Daniel.