5 Replies Latest reply on Oct 2, 2009 11:01 PM by Alan Feng

    What is an invocation, and the related option override?

    Alan Feng Novice


      I'd appreciate some clarification regarding the Invocation concept. What is considered an invocation?

      It looks like JBC uses ThreadLocal to store transaction and InvocationContext, so it appears to me that a invocation is basically having the same lifespan as a thread. Is this correct? What if the thread is pooled and reused?

      The reason this is important is that the cache "option overrides" are per "Invocation". In other words, if I set and option override, it last for that invocation. Therefore, clarifying on the "invocation" concept becomes necessary but I wasn't able to find a good straight answer on it.

      Thanks in advance,

      Alan

        • 1. Re: What is an invocation, and the related option override?
          Mircea Markus Master

          invocation = an operation executed against the cache, e.g. cache.put(fqn, k, v)

          • 2. Re: What is an invocation, and the related option override?
            Alan Feng Novice

            Thanks for the reply.

            So if I need to read a node, then write to it, such as:

             tm.begin();
             // force write lock even on read operations
             cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);
            
             // read node
             Object value = cache.get(myFqn, "key");
            
             // write node
             cache.put(myFqn, "key", "newValue");
            
             tm.commit();
            


            Will the "setForceWriteLock(true)" applied to both cache.get() and cache.put() operations?

            It looks like the InvocationContext is a ThreadLocal variable (looking at the CacheInvocationDelegate class), which means it lasts as long as the thread is still active. In other words, once I set the "setForceWriteLock(true)", all future cache related operations in this thread will see this option set to "true". And if a thread pool is used in my application for processing (such as a pool of JMS consumer threads), I won't know which options are set and which aren't.

            Is my observation correct?

            Thanks,



            • 3. Re: What is an invocation, and the related option override?
              Mircea Markus Master

              it only makes sense to use setForceWriteLock(true) on read. Normally when you do an cache.get(fqn) an read lock is aquired, but setting the forceWriteLock to true would force a write lock acquisition. when you do a put(fqn)(generally a write), a WL (write lock) is acquired so having the flag is redundant. As a general rule, the forceWriteLock only apply for one call, i.e. for one invocation.

              tm.begin();
               // force write lock even on read operations
               cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);
              
               // read node
               Object value = cache.get(myFqn, "key");
              
               Object value = cache.get(myFqn2, "key");
              
               tm.commit();


              In this example a WL is acquired for myFqn and a RL is acquired for myFqn2

              In other words, once I set the "setForceWriteLock(true)", all future cache related operations in this thread will see this option set to "true".
              No. Only the next call, after that the flag is cleaned. As mentioned in the previous post, an invocation is an call to the cache.

              • 4. Re: What is an invocation, and the related option override?
                Alan Feng Novice

                Thanks for the reply!

                Your explanation makes sense, however, it seems conflict with sample in the http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/3.2.0.GA/userguide_en/html_single/index.html#configuration.options.


                Will that be true that if the override is inside a transaction, the lock will be kept for the rest of the transaction?

                • 5. Re: What is an invocation, and the related option override?
                  Alan Feng Novice

                   

                  "mircea.markus" wrote:
                  it only makes sense to use setForceWriteLock(true) on read. Normally when you do an cache.get(fqn) an read lock is aquired, but setting the forceWriteLock to true would force a write lock acquisition. when you do a put(fqn)(generally a write), a WL (write lock) is acquired so having the flag is redundant. As a general rule, the forceWriteLock only apply for one call, i.e. for one invocation.
                  tm.begin();
                   // force write lock even on read operations
                   cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);
                  
                   // read node
                   Object value = cache.get(myFqn, "key");
                  
                   Object value = cache.get(myFqn2, "key");
                  
                   tm.commit();


                  In this example a WL is acquired for myFqn and a RL is acquired for myFqn2

                  In other words, once I set the "setForceWriteLock(true)", all future cache related operations in this thread will see this option set to "true".
                  No. Only the next call, after that the flag is cleaned. As mentioned in the previous post, an invocation is an call to the cache.


                  I did a quick test and you are absolutely right. Just like what you pointed out in your sample code, after each read or write, the over write option is reset. This clears the confusion I had. Thanks!

                  The reason for this post was that I'm trying to find a reliable way to do a "select for update" kind of operation in the new MVCC locking, i.e., a read followed by a write and the write value depends on the read result. Could you please comment on this thread?
                  http://www.jboss.org/index.html?module=bb&op=viewtopic&t=161530&postdays=0&postorder=asc&start=0