6 Replies Latest reply on May 22, 2002 5:30 PM by dsundstrom

    LockInterceptor and Transactions

    jgeisler

      Hi,
      looking through the container conf xml I found an entry for a LockInterceptor. I find this rather strange since I thought transaction isolation and concurrency issues are handled at the resource level and not upon method invocation. Can anyone explain how this comes together?
      Thanks, Jens

        • 1. Re: LockInterceptor and Transactions
          dsundstrom

          The LockInterceptor handles the EJB locking requirements. For example, you could be accessing a single Stateful Session Bean, and the EJB spec requires exclusive access to the object. Also, the interceptors handle the XA stuff where you acces multiple databases.

          Got it?

          • 2. Re: LockInterceptor and Transactions
            jgeisler

            Nope, I'm afraid not. Maybe it's just too simple. Does that mean that my Bean always works for one client at a time, no matter how many are trying to access it concurrently? Does this further more mean that my EntityBeans will always have an exclusive lock on their table row give it is the only one which uses it?
            No matter how anti-transactional my DB is?
            In case of a DB only being accessed by JBoss and each table being used by only one Bean class that would make the whole transaction stuff expendable?

            Jens

            • 3. Re: LockInterceptor and Transactions
              dsundstrom

              > Nope, I'm afraid not. Maybe it's just too simple.
              > Does that mean that my Bean always works for one
              > client at a time, no matter how many are trying to
              > access it concurrently?

              Usually, you can change the lock to a multi-instance lock, but you don't get much of a performance improvement. The EJB spec says that a bean instance can only be accessed by one thread at a time.

              > Does this further more mean
              > that my EntityBeans will always have an exclusive
              > lock on their table row give it is the only one which
              > uses it?

              No table row locks are a completely different issue. If you want row locks you have to turn it on in the CMP manager, or do it your self in BMP code.

              > No matter how anti-transactional my DB is?

              See above.

              > In case of a DB only being accessed by JBoss and each
              > table being used by only one Bean class that would
              > make the whole transaction stuff expendable?

              Not exactly. Transactions are necessary to coordinate changes across multiple resources (DB, MQ, etc), and handling concurrency. If you don't care about concurrency, just mark all of the methods as requires new transaction. This will limit a tx to a single method call. Transactions in JBoss have very little overhead (basically unmeasurable). If you do this, you set your beans to use commit option A, or you will get very bad performance.

              Any way this is a huge topic and if you are really interested in locking, transactions and interceptors you need to attend the JBoss training. They spend an entire day on optimization.

              • 4. Re: LockInterceptor and Transactions
                dsundstrom

                > Nope, I'm afraid not. Maybe it's just too simple.
                > Does that mean that my Bean always works for one
                > client at a time, no matter how many are trying to
                > access it concurrently?

                Usually, you can change the lock to a multi-instance lock, but you don't get much of a performance improvement. The EJB spec says that a bean instance can only be accessed by one thread at a time.

                > Does this further more mean
                > that my EntityBeans will always have an exclusive
                > lock on their table row give it is the only one which
                > uses it?

                No table row locks are a completely different issue. If you want row locks you have to turn it on in the CMP manager, or do it your self in BMP code.

                > No matter how anti-transactional my DB is?

                See above.

                > In case of a DB only being accessed by JBoss and each
                > table being used by only one Bean class that would
                > make the whole transaction stuff expendable?

                Not exactly. Transactions are necessary to coordinate changes across multiple resources (DB, MQ, etc), and handling concurrency. If you don't care about concurrency, just mark all of the methods as requires new transaction. This will limit a tx to a single method call. Transactions in JBoss have very little overhead (basically unmeasurable). If you do this, you set your beans to use commit option A, or you will get very bad performance.

                Any way this is a huge topic and if you are really interested in locking, transactions and interceptors you need to attend the JBoss training. They spend an entire day on optimization.

                • 5. Re: LockInterceptor and Transactions
                  dsundstrom

                  > Nope, I'm afraid not. Maybe it's just too simple.
                  > Does that mean that my Bean always works for one
                  > client at a time, no matter how many are trying to
                  > access it concurrently?

                  Usually, you can change the lock to a multi-instance lock, but you don't get much of a performance improvement. The EJB spec says that a bean instance can only be accessed by one thread at a time.

                  > Does this further more mean
                  > that my EntityBeans will always have an exclusive
                  > lock on their table row give it is the only one which
                  > uses it?

                  No table row locks are a completely different issue. If you want row locks you have to turn it on in the CMP manager, or do it your self in BMP code.

                  > No matter how anti-transactional my DB is?

                  See above.

                  > In case of a DB only being accessed by JBoss and each
                  > table being used by only one Bean class that would
                  > make the whole transaction stuff expendable?

                  Not exactly. Transactions are necessary to coordinate changes across multiple resources (DB, MQ, etc), and handling concurrency. If you don't care about concurrency, just mark all of the methods as requires new transaction. This will limit a tx to a single method call. Transactions in JBoss have very little overhead (basically unmeasurable). If you do this, you set your beans to use commit option A, or you will get very bad performance.

                  Any way this is a huge topic and if you are really interested in locking, transactions and interceptors you need to attend the JBoss training. They spend an entire day on optimization.

                  • 6. Re: LockInterceptor and Transactions
                    dsundstrom

                    > Nope, I'm afraid not. Maybe it's just too simple.
                    > Does that mean that my Bean always works for one
                    > client at a time, no matter how many are trying to
                    > access it concurrently?

                    Usually, you can change the lock to a multi-instance lock, but you don't get much of a performance improvement. The EJB spec says that a bean instance can only be accessed by one thread at a time.

                    > Does this further more mean
                    > that my EntityBeans will always have an exclusive
                    > lock on their table row give it is the only one which
                    > uses it?

                    No table row locks are a completely different issue. If you want row locks you have to turn it on in the CMP manager, or do it your self in BMP code.

                    > No matter how anti-transactional my DB is?

                    See above.

                    > In case of a DB only being accessed by JBoss and each
                    > table being used by only one Bean class that would
                    > make the whole transaction stuff expendable?

                    Not exactly. Transactions are necessary to coordinate changes across multiple resources (DB, MQ, etc), and handling concurrency. If you don't care about concurrency, just mark all of the methods as requires new transaction. This will limit a tx to a single method call. Transactions in JBoss have very little overhead (basically unmeasurable). If you do this, you set your beans to use commit option A, or you will get very bad performance.

                    Any way this is a huge topic and if you are really interested in locking, transactions and interceptors you need to attend the JBoss training. They spend an entire day on optimization.