7 Replies Latest reply on Nov 17, 2002 10:24 PM by fox_hk

    question about commit-option and

    fox_hk

      Hi all jboss guru

      It is thankful somebody can share with me your insight in following questions

      1) l have set the commit option to C. Hence,a CMP will be synchronzied with db as it is invoked. It seems that making the cache pool size bigger than 1 become pointless. Am l correct ?

      2) As l set the cache size to a very small value. l find that findbyPrimaryKey method will fail to retrieve the CMP as a large amount of CMP (~100) are retrieved in a for loop. But as l set it the cache size to a very big value. The "findbyPrimaryKey" method invoked within that for loop will function properly. WHY ???

      As l trace the log file, l find that the persistence manager will issue a "select count(*) from table where id = ?" and then issue another sql statement to load the attributes as any "setter" method is called. l think the persistence manager sometimes will pass a null primary key as a parameter to that select statement for loading the attributes of CMP. why ??

      regards
      fox

        • 1. Re: question about commit-option and
          fox_hk

          l forgot to mention l use jboss 2.4.8 on win 2000

          • 2. Re: question about commit-option and
            vickyk

            Hi fox,
            > 1) l have set the commit option to C. Hence,a CMP
            > will be synchronzied with db as it is invoked. It
            > seems that making the cache pool size bigger than 1
            > become pointless. Am l correct ?
            Why are setting the cache pool size,the commit option C just specifies the instance will remain in the ready State till the mapped data is available or timeout reaches or you call remove.I have never set the cache pool size but I do change the commit options.Any way there will be just a single instance for a particular CMP at any instance of time.
            > 2) As l set the cache size to a very small value. l
            > find that findbyPrimaryKey method will fail to
            > retrieve the CMP as a large amount of CMP (~100) are
            > retrieved in a for loop. But as l set it the cache
            > size to a very big value. The "findbyPrimaryKey"
            > method invoked within that for loop will function
            > properly. WHY ???
            Are you able to get the Collection of the Remote Reference,I mean does your findermethod fails while giving you the remote reference or when you manapulate a particular bean instance from the Collection returened from findermethod?
            Regards
            Vicky

            • 3. Re: question about commit-option and
              fox_hk

              the snippet of code is as follows

              for(..){
              remoteref = homehandle.findbyPrimaryKey();
              System.out.println(remoteref.getPrimarykey());
              remoteref.setxxx(value obj);
              }

              The print statement can successfully print out the primary key. It fail when setter is called. But when l checked the error log, l find the persistence manager will issue a SQL select statement to load columns data from db. Primary key will be passed as parameter for that SQL statement. Amid for loop, when invocation of setter failed, l find a null parameter is passed to that SQL select statement. When l increase the cache size, the for loop can execute more times before it hit the same problem. Why ??? any idea ??? Is it a bug in jboss 2.4.8

              many thanks
              fox

              • 4. Re: question about commit-option and
                vickyk

                Hi,
                Can you try this with Jboss3.*?
                Ideally it should not happen as per my undestanding.As you are setting the max pool size to 1 and as you keep on iterating the finder the instance move from the pooled state to readystate(cached state) where it should remain till the timeout called by container is called or forced by some restriction (here I mean the max limit specified)
                Regards
                Vicky

                • 5. Re: question about commit-option and
                  fox_hk

                  Sorry, my system is using jboss 2.4.x to carry out development by far. we can't afford to upgrade to 3.x. It may involves so much changes. Yes, l set the cache size to 1 and pool size to a high value. But l also try out a medium cache size such as 10,20. But the problem exists too. But the exception just take place after for-loop run more times.

                  many thanks
                  fox

                  • 6. Re: question about commit-option and
                    vickyk

                    Hi,
                    What is making you to change the cache size? Is you application running short of the resource(memory)?
                    I will try the same with 3.0.2 and let you know but not now as I have some assignment lying to finish
                    Regards
                    Vicky

                    • 7. Re: question about commit-option and
                      fox_hk

                      Dear Vicky

                      thank for your kind attention to my question. Because my db is shared by other app, l change the commit-option to C. l think the "cache" can't do any good to the performance of entity bean. l tried out various cache size and monitor the server.log file. l found that cache size makes no difference in SQL statements issued by persistence manager, Is it a wiser choice to turn off the cache pool because l found that the abovementioned disappear if cache pool is off. Because is my configuration. Please comment on it.

                      <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>