6 Replies Latest reply on Nov 22, 2002 1:06 AM by Vicky Kak

    commit-option "C" implies cache pool of CMP becomes of no us

    fox Newbie

      Hi All

      Because my db is shared by other app, l set the commit-option to C. In this case, l think the "cache pool" for entity bean CANNOT do any good to the performance of entity bean. l tried out various cache pool size and monitored the server.log file. l found that cache size made no difference in SQL statements issued by persistence manager, Is it a wiser choice to turn off the cache pool ? Below is my configuration, it is thankful you can comment on it if it is no appropriate.

      <container-cache-conf>
      <cache-policy>org.jboss.ejb.plugins.NoPassivationCachePolicy</cache-policy>
      <!--
      cache-policy-conf>
      <min-capacity>10</min-capacity>
      <max-capacity>60</max-capacity>
      <overager-period>300</overager-period>
      <max-bean-age>600</max-bean-age>
      <resizer-period>400</resizer-period>
      <max-cache-miss-period>60</max-cache-miss-period>
      <min-cache-miss-period>1</min-cache-miss-period>
      <cache-load-factor>0.75</cache-load-factor>
      </cache-policy-conf>
      -->
      </container-cache-conf>

      <container-pool-conf>
      60
      10
      </container-pool-conf>
      <commit-option>C</commit-option>

      many thanks
      fox

        • 1. Re: commit-option "C" implies cache pool of CMP becomes of n
          Horia Muntean Newbie

          Yep. Take a look at the specs (EJB specs from java.sun.com). Commit option B makes the entity cahe unusable too. With those options, the container loads (via ejbLoad) the entity from the DB at the begining of a new transaction. The only commit option you can use in order to cache your entities betwen transactions is commit option A. But u can't use the last one if u share your DB with other apps.

          • 2. Re: commit-option "C" implies cache pool of CMP becomes of n
            fox Newbie

            Hi all

            l tried out comment out the tag <container-cache-conf> / <cache-policy-conf>, but jboss rejected it even the DTD of jboss.xml allow to do so (weird ??). What l am concerned is whether or not using the tag
            "<cache-policy>org.jboss.ejb.plugins.NoPassivationCachePolicy</cache-policy>" is technically equivalent to switch off cache pool. Because the manual just say that this policy will make CMP not passivate. It doesn't explicitely say what happen when the max pool size is reached ....
            Please advice

            fox

            • 3. Re: commit-option "C" implies cache pool of CMP becomes of n
              Vicky Kak Master

              Hi
              > Hi All
              >
              > Because my db is shared by other app, l set the
              > commit-option to C. In this case, l think the "cache
              > pool" for entity bean CANNOT do any good to the
              > performance of entity bean. l tried out various cache
              > pool size and monitored the server.log file. l found
              > that cache size made no difference in SQL statements
              > issued by persistence manager, Is it a wiser choice
              > to turn off the cache pool ? Below is my
              > configuration, it is thankful you can comment on it
              > if it is no appropriate.
              >
              > <container-cache-conf>
              > <cache-policy>org.jboss.ejb.plugins.NoPassivationCache
              > olicy</cache-policy>
              Let me share my opinion and my understanding,I dont have have the docs and I have learnt the Jboss management just by applying the basics and referring to the Quick ref pdf.
              I do agree with you but considering that there being some sort of the blockage in the method call which can result in cpu sit idle.At the same moment take a scenario where all the bean-pooled instance are busy in calling mean while a fresh call has appeared then what happens?
              Here I can visualize two possibility one at the appearance of call it find a bean calling the method having blockage,hence the bean is passivate at this momemt and serves the other call.So here there can be caching coming in the picture.
              So if you make the changes in
              <container-pool-conf>
              60
              10
              </container-pool-conf>
              I think you get some thing you expect I mean the caching.
              Hope you share some more info .
              Regards
              Vicky

              • 4. Re: commit-option "C" implies cache pool of CMP becomes of n
                Vicky Kak Master

                Hi
                > Hi All
                >
                > Because my db is shared by other app, l set the
                > commit-option to C. In this case, l think the "cache
                > pool" for entity bean CANNOT do any good to the
                > performance of entity bean. l tried out various cache
                > pool size and monitored the server.log file. l found
                > that cache size made no difference in SQL statements
                > issued by persistence manager, Is it a wiser choice
                > to turn off the cache pool ? Below is my
                > configuration, it is thankful you can comment on it
                > if it is no appropriate.
                >
                > <container-cache-conf>
                > <cache-policy>org.jboss.ejb.plugins.NoPassivationCache
                > olicy</cache-policy>
                Let me share my opinion and my understanding,I dont have have the docs and I have learnt the Jboss management just by applying the basics and referring to the Quick ref pdf.
                I do agree with you but considering that there being some sort of the blockage in the method call which can result in cpu sit idle.At the same moment take a scenario where all the bean-pooled instance are busy in calling mean while a fresh call has appeared then what happens?
                Here I can visualize two possibility one at the appearance of call it find a bean calling the method having blockage,hence the bean is passivate at this momemt and serves the other call.So here there can be caching coming in the picture.
                So if you make the changes in
                <container-pool-conf>
                60
                10
                </container-pool-conf>
                I think you get some thing you expect I mean the caching.
                Hope you share some more info .
                Regards
                Vicky

                • 5. Re: commit-option "C" implies cache pool of CMP becomes of n
                  fox Newbie

                  Dear vicky

                  thanks you very much for your response. But l can't get your point. How can cache affect passivation in the case you quoted ??? It is highly appreciated if you can elaborate on it further

                  regards
                  fox

                  • 6. Re: commit-option "C" implies cache pool of CMP becomes of n
                    Vicky Kak Master

                    Hi fox,
                    Considering there the limit of 10 beans in cache and if the load increases and there are not beans in the pooled state to serve the request.What will happen then?
                    Two Cases:
                    1)The request has to wait till the bean instance is returned to pooled instance,which will happen once the transaction ends up.(In case of the Commit Option B)
                    2)Pick up the bean from the cache which is waiting for some resource,if available(I mean if such entity exists).If this is found then till the time resource is made available to that you can make the same instance serve the addition request appeared.So there comes your passivation.The passivation is just the data instance state getting stored.
                    I am talking of the second case which can occur of the heavy load.
                    Hope now it is clearer ,I am extremely sorry for the last post not properly explained.
                    Regards
                    Vicky