5 Replies Latest reply on May 6, 2002 2:33 PM by davidjencks

    ejbLoad get called all the times

    redhonda

      I have a cmp entity beans with some getXXX() methods defined. Each time one of the getXXX()'s get called, the container also calls ejbLoad(). Doesn't make sense to do ejbLoad() on get's. Even when I set the transaction attribute to NotSupported in ejb-jar.xml, it still does that. Am I doing something wrong? I prefer not to call ejbLoad on get's.

      Anyone has an answer?

      Thanks

        • 1. Re: ejbLoad get called all the times
          dsundstrom

          Use a transaction. Loaded values are only valid for the life of a transaction.

          • 2. Re: ejbLoad get called all the times
            redhonda

            You mean the client should be in a transaction when calling the getXXX()'s and keep the "Required" container attribute?

            • 3. Re: ejbLoad get called all the times
              dsundstrom

              Yes. Transaction granularity is a hey factor in performance. If you use micro transaction, you will see lots of loads. Each time you call a read method on your bean, JBoss has to reload the data because it could have changed since the last transaction was committed.

              • 4. Re: ejbLoad get called all the times
                redhonda

                Any good examples out there that illustrate the use of container and bean managed transactions. After reading a number of resources, still don't even know how to use when you have entity beans, servlets, JSPs in an app. What about if you want clients to participate in transactions?

                • 5. Re: ejbLoad get called all the times
                  davidjencks

                  1. Don't use BMT

                  2. Don't use userTransaction in clients

                  3. Demarcate your transactions as methods on session beans.

                  In other words, every transaction should be started and ended by some method call on a session bean. (Except possibly for weird things like getting unique id values in a separate tx)

                  If your application doesn't seem to want to fit in this model, change its architecture.

                  This may seem a little extreme, but in general I think it is a good principle.