ejb transaction and threading issues

[saahil sinha]

1)How are threading issuues handled in ejb?
2)Does the container manage transactions for both cmp and bmp or transactions are to be coded for bmp?
3)What is the advantage of using ejb over servlets?
4)If i am to provide updations to a database,insertions and deletions in a multi user environment is it better to user servlets or beans .Why?

[Lasse Koskela]

1)How are threading issuues handled in ejb?

The issues are handled by the EJB Container. The bean developer is not allowed to use threads (meaning that you can use them but at your own risk -- the appserver vendor does not make any promises).

2)Does the container manage transactions for both cmp and bmp or transactions are to be coded for bmp?

The term "Container-Managed Transactions" (CMT) is only applicable to CMP entity beans, not BMP entity beans, for the simple reason that the container does not know what the bean provider has been doing inside the BMP (for example, the BMP might make updates to two separate databases and the container has no way of knowing how it should declare transactions for these two operations as individuals and as a group).

3)What is the advantage of using ejb over servlets?

I tried to answer this one here.

4)If i am to provide updations to a database, insertions and deletions in a multi user environment is it better to user servlets or beans .Why?

You shouldn't do this in a servlet because you will not be able to reuse that functionality later on without cut'n'pasting the code from the servlet to another servlet/regular class.
Whether it's better to use EntityBeans or the Data Access Object (DAO) pattern is really dependent on the type/frequency/complexity/etc of the updates being performed on the database. You should describe these updates in more detail if you want to discuss the "best" tool to use.

[Steve Chernyak]

The term "Container-Managed Transactions" (CMT) is only applicable to CMP entity beans, not BMP entity beans, for the simple reason that the container does not know what the bean provider has been doing inside the BMP (for example, the BMP might make updates to two separate databases and the container has no way of knowing how it should declare transactions for these two operations as individuals and as a group).

Are you sure about that?
I thought that any transaction aware resource would participate in a container managed transaction.
For example: If your session bean doesn't use entity beans at all but jdo instead, if the connection used by jdo to access the database supports transactions any changes made to the database using that connection would be commited/rolledback depending on the success/failure of the container managed transaction.
Assuming that you configure the session bean with CMT.
Is this wrong?

[Chris Mathews]

Originally posted by Lasse Koskela:
The term "Container-Managed Transactions" (CMT) is only applicable to CMP entity beans, not BMP entity beans, for the simple reason that the container does not know what the bean provider has been doing inside the BMP (for example, the BMP might make updates to two separate databases and the container has no way of knowing how it should declare transactions for these two operations as individuals and as a group).

Actually CMT applies equally to BMP and CMP. In fact, CMT is required for either type of Entity Bean.

EJB 2.0 Specification Section 17.3.1
A Session Bean or a Message-driven Bean can be designed with bean-managed transaction demarcation
or with container-managed transaction demarcation. (But it cannot be both at the same time.)
An Entity Bean must always be designed with container-managed transaction demarcation.

[Lasse Koskela]

Actually CMT applies equally to BMP and CMP. In fact, CMT is required for either type of Entity Bean.

Correct. My bad. You must have CMT with Entity Beans. (I actually looked it up from the spec when I wrote the post but got somehow tangled up with my words)
Steve, if a SessionBean having a transactional context calls something leading to a managed resource update, the update is registered to the same existing transaction. It doesn't matter whether the transaction was created by the container (CMT) or the bean code (BMT).