5 Replies Latest reply on Aug 25, 2004 9:21 PM by ioparra

    Inst. Per Tx with Cache Invalidation?

    ioparra

      First of all, is this an option? How about with optimistic locking?

      To enable cache, there are 2 changes:
      1) additional EntityBeanChaceBatchInvalidatorInterceptor
      2)change cache to InvalidableEntityInstanceCache

      To enable InstancePerTx, there is 1 change:
      1)PerTxEntityInstanceCache

      The fundamental issue I can see here is if the CacheInvalidation assumed QueuedPessimisticLocking, then there would only be one instance per container. If so, then the actually cached version may be the context given to any one request instead of a copy of the context,which disables an InstancePerTx option. To make perTx work, the cache would need to clone all cacheable objects before giving it to the client. Is this even possible? Would something need to be added to the container that would allow a cloning of a context w/o hitting the DB?

      For InstancePerTx, it appears that each Tx has its own cache(via TransactionLocal) and loads the values directly from the container on a miss. This allows multiple instances of the same entity, each individually loaded from the DB seperately. If on a miss, it checks a container level cache and clones it during a hit, this still may work. But that leaves results with a container cloning w/o a db hit problem.

      At first glance, I looks like this option is not available b/c of a container management/cloning issue. Suggestions? or enhancement?

      -Ivan


      JDK1.3.1_06
      JBoss3_2_5
      Oracle9i
      Window2000Adv.Server

        • 1. Re: Inst. Per Tx with Cache Invalidation?
          aloubyansky

          Check JBossCMP wiki for caching and locking.
          You could use IPT for read-write container and standard container configuration with commit option A and cache invalidation for read-only container.

          • 2. Re: Inst. Per Tx with Cache Invalidation?
            ioparra

            Thanks Alex-

            Read through the documentation(including paid docs) and have a few more clarifications:

            1)AdminDevel_323.Page 302

            The JBoss developers are currently exploring ways to allow commit-option ‘A’ as well (which would allow the use of caching for this option).


            Referring to IPT. Any updates on this progress for the 3.2 branch?

            2)From CMP Wiki,
            Therefore, such verbal nonsense like 'container with pessimistic locking policy configured with CMP optimistic locking' might make sense in some clustered deployments.

            For Entity with Cache Invalidation, when 2 transactions in seperate nodes modify the same row, to make sure you have data integrity, optimistic locking would be required. But this container is defaulted to QueuedPessimistic. For a clustered environment(not clustered entities), this nonsense makes sense... right?

            Which leads me to:

            3)What happens if CMP with Cache invalid is deployed without pessimistic locking(ie nolock or optim). Since there is only one instance, this would imply that all transactions would have complete reign over the entity and any one of them can read/modify the ejb, randomly commiting and rolling back.(sounds like a tragedy to me).

            Thanks a bunch!
            -Ivan



            • 3. Re: Inst. Per Tx with Cache Invalidation?
              ioparra

              Sorry, one more thing... For #2, how do you configure optimistic+pessimistic at the same time if only one locking policy is available per container?

              -I

              • 4. Re: Inst. Per Tx with Cache Invalidation?
                aloubyansky

                1) yes, 3.2.6 will include a new container configuration


                <container-configuration>
                <!--
                | This is like standard IPT but with global (cross-transactional) row cache behind,
                | i.e. no locking in EJB layer + global persistence data cache
                -->
                <container-name>cmp2.x jdbc2 pm</container-name>

                This container is a new implementation and does not have all the features of the current standard container. This was driven by SPECjAppServer2002 optimization work.

                2) Right. Cache invalidation is irrelevant details here since one tx or another will invalidate it anyway.

                3) Not clear for me. In cache invalidation you have two containers: RW and RO. RW can be based on IPT or Standard container. RO should be based on the standard container with CO A and possibly marked as read-only assuming it's not going to be modified.

                4) Read the Locking page again where it says

                Optimistic locking is not a locking policy in terms of locking policies described above,


                • 5. Re: Inst. Per Tx with Cache Invalidation?
                  ioparra

                  Thanks Alex, just a few more questions:

                  Sorry for taking so long, I wanted to have a look at the new container

                  1)I noticed that the their is no Cache Invalidation trigger for this container. Since it is commit option C, how long does this cache live? Is it invalidated by the InvalidationManager or is it lost at the end of all the tx? What kind of performance gain is suspected from this container.

                  From the documentation, I got the impression that there would be a global cache and when each IPT begins it would either Clone a context from the global cache(on a hit) or create a context in both the global/local cache(on a miss). I'm guessing that was not the goal for SPECjAppServer2002 opt.

                  2)Any suggestions on a read-mostly scenario with data integrity. In other words an entity is created, but is only update 1% of the time. When it is updated an invalidation occurs. What happens if this same 1% time occurs on 2 seperate nodes(unlikely, but possible), both are CacheInvalidation/Pessimistic and both will update the db based on the PK, the last update will win. If instead this contianer had optimistic lock, the update for the second instance would fail and the app would need to handle the error. Is this configuration possible? Based on the documentation, it seems like it should be. How? The container descriptor does not have a place for both pessimistic/optimistic to co-exist. Am I missing a configuration placement?

                  3,4) Thanks for clarifying.

                  -Ivan