-
1. Re: LockInterceptor and Transactions
dsundstrom May 22, 2002 10:48 AM (in response to jgeisler)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 May 22, 2002 12:46 PM (in response to 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 May 22, 2002 5:27 PM (in response to 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?
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 May 22, 2002 5:27 PM (in response to 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?
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 May 22, 2002 5:28 PM (in response to 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?
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 May 22, 2002 5:30 PM (in response to 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?
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.