8 Replies Latest reply on Oct 1, 2003 3:24 AM by semi

    Commit Option A and "store" method calls...

    semi

      Hi,

      We use <commit-option>A</commit-option> but the CMP beans seems not to be cached at all.

      No matter, which one adjusts, the method "store" is called again and again after each access to the bean.
      All that within the same transaction!

      In BMP one can prevent this with a "dirty"-flag in the setter, the load and store methods.
      How to do it in a CMP-Bean?
      Does caching in jboss 3.0.0 work at all?

      Here a cutout from the container configuration in standardjboss.xml
      ---------------------
      ...
      <container-cache-conf>
      <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
      <cache-policy-conf>
      <min-capacity>50</min-capacity>
      <max-capacity>1000000</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>
      100
      </container-pool-conf>

      <commit-option>A</commit-option>
      ...
      ------------------

      ... and from standardjbosscmp-jdbc.xml
      ------------------

      java:/SAPDBDS
      <datasource-mapping>SapDB</datasource-mapping>
      <create-table>false</create-table>
      <remove-table>false</remove-table>
      <read-only>false</read-only>
      <time-out>300</time-out>
      <pk-constraint>true</pk-constraint>
      <fk-constraint>false</fk-constraint>
      <row-locking>false</row-locking>
      <preferred-relation-mapping>foreign-key</preferred-relation-mapping>
      <read-ahead>
      on-load
      <page-size>1000</page-size>
      <eager-load-group>*</eager-load-group>
      </read-ahead>
      <list-cache-max>5000</list-cache-max>

      ------------------

      Please help
      Michael

        • 1. Re: Commit Option A and "store" method calls...
          ioparra

          Are you using the Entity per Transaction or Entity per Container?

          • 2. Re: Commit Option A and "store" method calls...
            semi

            Hi, thanks for the answer.

            All the CMP's are in the same container.
            The transaction is initiated in a session facade. All entity-beans have the transaction attribute "Required" and are accessed localy. Furthermore we are using container managed transaction.

            Is there a way to see in CMT-Mode, when a container starts a new transaction?

            Regards,
            Michael

            • 3. Re: Commit Option A and "store" method calls...
              manuelf

              Hi Michael,

              ioparras question was which container configuration did you use for your entity beans? The Standard CMP 2.0 or the entity per transaction config stuff?

              Are you calling finders between your entity-bean access? If so the cmp engine must write back any changed data before issuing the finder call. So keep the right order in you tx - first all read operations - then write (update/create/remove).

              cheers,

              Manuel

              • 4. Re: Commit Option A and "store" method calls...
                semi

                Hi Manuel,

                the beans are in the "Standard CMP 2.x Container" (the first one configured in ...server/default/conf/standardjboss.xml)

                "entity per transaction config stuff"
                Which one is that?

                yes I call few finder methods on the home interface of one of the entity-beans.
                There is no write access to those beans at all (not during this one transaction)
                It is a huge bunch of rows from a database table I have to iterate through. One of the finder called is findAll() and there are about 4000 rows in the table.
                I know it's a good candidate for readonly beans, but the table is sometimes accessed in write mode too.

                We used CachedRowset's before (accessed from a session bean (in a separate DB-Class)) to read the table and some sort of object cache within the session bean. It's very fast, but can become inconsistent, when things changes.

                ...calling finders between your entity-bean access? If so the cmp engine must write back any changed data before issuing the finder call

                Yes I know this from the EJB spec. (did never understand why it happens, when nothing changes)
                We hopped, that JBoss writes changed entities only back to the table (similar to using isModified() in BMP)

                Is there a way to prevent the beans from beeing (unnecessarily) stored in the db, when nothing changes?

                Michael

                • 5. Re: Commit Option A and "store" method calls...
                  manuelf

                  Hi Michael,

                  > Hi Manuel,
                  >
                  >......
                  > "entity per transaction config stuff"
                  > Which one is that?

                  configuration is called
                  "Instance Per Transaction CMP 2.x EntityBean" and doesn't work in conjunction with Commit-Option A.

                  it's good practice to declare methods of your entity-bean which do not change its state as readonly - therefore entity locks are holded only for the duration of the bean method invocation - not the entire tx.

                  your case seems kind of weired to me - normaly the cmp engine checks if any entity-bean fields have changed - so no unnecessary updates are promoted to the DB. Turn on cmp-tracing in log4.xml and look at the server.log if updates are really happening (package org.jboss.ejb.plugins.cmp).

                  cheers,

                  Manuel

                  • 6. Re: Commit Option A and "store" method calls...
                    semi

                    Hi,

                    yes after setting the tracing for the package
                    org.jboss.ejb.plugins.cmp I see thousends of calls to the ejbStore method. It is such slow that a transaction timeout occurs :)

                    I tried another locking policy (in standardjboss.xml)

                    <locking-policy>org.jboss.ejb.plugins.lock.MethodOnlyEJBLock</locking-policy>

                    instead of

                    <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>

                    Things remain the same. After each invocation of a findWhatever method, the beans are synchronized against the database.
                    There are no bussiness methods or other state-changing-methods in the bean except the setter methods, which are never called in the above scenario.

                    Another test: All Entity-Beans set to "readonly".

                    The store method is never called (I would wonder if it was so :)) but it's not what I'm looking for. There are few usecaces, where some of the entities are changed (monthly updates for example). I do not like to write two separate beans to access the table (readonly and an update-bean)

                    Is it necessary (or possible) to declare all getter-methods as readonly still beeing able to update the beans?

                    In my understanding of the container functionality, the container "installs" some kind of a proxy/wrapper object for each bean instanciated to "see" what happens to it. If a setter method is called, the bean becomes "dirty". In all other cases there is no need to synchronize.

                    Do you have a working configuration (standardjboss.xml) or an example that behaves as expected?

                    Perhaps, thanks again for your answer :)

                    Regards,
                    Michael

                    • 7. Re: Commit Option A and "store" method calls...
                      manuelf

                      Hi Michael,

                      I normally declare all getter methods on the entity beans component interface as "read-only".
                      However - I think what you see are a lot ejbStore calls in your entity beans, but no updates to the db. This is because of a known bug/shortcoming in the JDBCIsModifiedCommand in the cmp2 implementation. It is always returning true, which leads to unnecessary calls of ejbStore. But thank good it doesn't mean you get also unnecessary db updates, because the JDBCStoreManagers storeEntity()-method checks for modified fields and does NOT depend on JDBCIsModifiedCommand.

                      So I encourage you to check your logfiles for superflous SQL-Updates (maybe you can monitor this more effectivly with you db tools) - I am convinced there won't be any ;p

                      Cheers,

                      Manuel

                      • 8. Re: Commit Option A and "store" method calls...
                        semi

                        Hey, you are right :-)
                        There are no update statements for the tables on the sapdb trace log.
                        I know what my problem is. I couldn't belive it takes so much time to invoke the ejbStore method without writting anything to the table. All the validation stuff within the container is a real overkill for an application.

                        I think I have no other choices than to separate the readonly and write access. Maybe using one of the following patterns.

                        A.C.E. Smart Cache: http://www.theserverside.com/patterns/thread.jsp?thread_id=10610
                        Seppuku Pattern: http://www.theserverside.com/patterns/thread.jsp?thread_id=11280

                        Thanks again,
                        Michael