5 Replies Latest reply on Apr 30, 2002 11:39 PM by dsundstrom

    Transaction "Supports" causes NULL Pointer in getApplicatio

    soeiro

      Hello All

      I'm trying to access a simple CMP 2.0 EntityBean from a Statefull Session Bean. It is found by the foundAll() statement, but when it tries to use any of the method's getXX fields, JBOSS causes the following null pointer:

      --------------------
      16:05:51,621 ERROR [LogInterceptor] TransactionRolledbackException, causedBy:
      javax.transaction.TransactionRolledbackException: Error getting application tx data map.
      (...)
      Embedded Exception
      null at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getApplicationTxDataMap(JDBCStoreManager.java:238)
      ------------------

      This situation happens when the getXX method has its transaction type set to "Supports" or "NotSupported". If it is ran with "Required" it works (VERY slowly).

      Could anybody shed any light into this?

      I'm using JBOSS3RC1 from Sourceforge, Win2k, Oracle 8i as configured as the DataSource

      Thanks,

      Luis JB Soeiro

        • 1. Re:  Transaction "Supports" causes NULL Pointer in getApplic
          dsundstrom

          Change it to Required. JBossCMP does not support non-transactional entities.

          • 2. Re:  Transaction "Supports" causes NULL Pointer in getApplic
            soeiro

            Dain

            I have reverted the transaction to "Required", but I was trying to get things to run more quickly. Do you have any suggestions? The way it is now, it needs about 1 second to process only two methods: getName() and getAlias(). There is a Session Bean that reads about 800 entities (with findAll()) and then iterates through all of them to populate a list box (methos getName and getAlias). That's more than 10 minutes to show the first screen!

            Ok. I don't know what could be done that doesn't require throwing out our Object Model and using plain SQL queries for this. However, there are other situations that we would greatly like to preserve the Object Model.

            This method doesn't need to have transactions and could use caching and anything else that could speed it up a bit. We changed the standarjbosscmp-jdbc.xml to limit the cache to just 1 entry, but at each getXX it executes the folwing SQL statement:

            DEBUG [] Invoke: [1] getName()
            DEBUG [] Executing SQL: SELECT ID_ORGAO,NAM_ORGAO, ALS_ORGAO, ID_SUPERIOR FROM ORGAO WHERE (ID_ORGAO=?) OR (ID_ORGAO=?) OR ... 253 times
            DEBUG [] Invoke: [1] getAlias()
            DEBUG [] Executing SQL: SELECT ID_ORGAO,NAM_ORGAO, ALS_ORGAO, ID_SUPERIOR FROM ORGAO WHERE (ID_ORGAO=?) OR (ID_ORGAO=?) OR ... 253 times

            Since the caching that it is using ins't working (it issues the same command again for each of the 800 entities), how could we turn it off? At least we could have ejbLoad() working a bit faster if it only loaded one entity for each call (instead of 255 entities, as it seems).

            Thanks,

            Luis JB Soeiro

            • 3. Re:  Transaction "Supports" causes NULL Pointer in getApplic
              dsundstrom

              You have put JBossCMP in the worst possible loading senario. You have read-ahead on (by default) and you are accessing your bean using many micro transactions. This causes JBoss to load lots of extra data and immedately throw that data away, as the data is only valid for the length of the transaction.

              Wrap all of you access to the entity in a single transaction, and it will be much faster. If you don't want to do this, set the read-ahead strategy to none, but his will be much lower then using optimized loading.

              • 4. Re:  Transaction "Supports" causes NULL Pointer in getApplic
                soeiro

                Dain

                Thanks. Just by calling from a "Required" transaction method, total time decreased from 10 minutes to 13 seconds. Could you state briefly what are these values?

                <read-ahead>
                on-load
                10000
                <page-size>1000</page-size>
                <eager-load-group>*</eager-load-group>
                </read-ahead>
                <list-cache-max>100000</list-cache-max>

                I assume they are not measured in bytes, but in pages (and page is measured in bytes...). Do they have any limit to what it would become less effective? For example, seeting above X would just passivate everybean because of shortage of memmory Y.

                Thanks again, this saved the day.

                Luís JB Soeiro

                • 5. Re:  Transaction "Supports" causes NULL Pointer in getApplic
                  dsundstrom

                  From the dtd:

                  <!--
                  Specifies the read ahead strategy.
                  
                   <read-ahead>
                   <strategy>on-load</strategy>
                   <page-size>255</page-size>
                   <eager-load-group>*</eager-load-group>
                   </read-ahead>
                  -->
                  <!ELEMENT read-ahead (strategy, page-size?, eager-load-group?)>
                  
                  <!--
                  Specifies the strategy used to read-ahead data in queries.
                  
                  The strategy element must be one of the two following:
                   <strategy>none</strategy>
                   <strategy>on-load</strategy>
                   <strategy>on-find</strategy>
                  -->
                  <!ELEMENT strategy (#PCDATA)>
                  
                  
                  <!--
                  Specifies the number of entities that will be read in a single
                  read-ahead load query.
                  -->
                  <!ELEMENT page-size (#PCDATA)>
                  
                  
                  <!--
                  Specifies the number of simultaneous queries that can be tracked by
                  the cache for an entity.
                  -->
                  <!ELEMENT list-cache-max (#PCDATA)>
                  

                  list-cache-max may need more documentation. JBossCMP tracks the order of entities loaded from a query, and the order is used in the on-load strategy when loading the next 'n' entities. The assumption is you are iterating over the results in forward order.