Container-managed Transactions scope

[Rizwan]

I work on stateless session EJBs which are using Container-managed
Transactions. My Inserts, Updates and Deletes are inside an EJB method. I
never call any commit/rollback.

Now i am starting to use DAO pattern. So Inserts, Updates and Deletes are
available as DAO methods. Now the EJB calls the DAO methods to do this kind
of stuff. The DAOs are not doing any commit/rollback. My question is will
the Container-managed Transactions be extended to the DAOs automatically.

For example I have 3 updates as part of one transaction. These 3 updates are
available in 3 different DAOs. If any one of them fail I want to rollback
the whole transaction. Before when these 3 updates are inside EJB, I was
safe because of Container-managed Transactions. But now they are outside of
EJB and I dont know if this functionality will be available.

If container do keep track of transactions like that then how many nested
levels I can go on? In one particular scenario, my EJB calls a method in a
class which in turn calls DAOs for Inserts/Updates/Deletes. Will they be
part of Container-managed Transactions as well?

Thanks

Rizwan

 

[Rizwan]

Anybody please?

 

[John C. Bollinger]

I work on stateless session EJBs which are using Container-managed
Transactions. My Inserts, Updates and Deletes are inside an EJB method. I
never call any commit/rollback.

Now i am starting to use DAO pattern. So Inserts, Updates and Deletes are
available as DAO methods. Now the EJB calls the DAO methods to do this kind
of stuff. The DAOs are not doing any commit/rollback. My question is will
the Container-managed Transactions be extended to the DAOs automatically.

For example I have 3 updates as part of one transaction. These 3 updates are
available in 3 different DAOs. If any one of them fail I want to rollback
the whole transaction. Before when these 3 updates are inside EJB, I was
safe because of Container-managed Transactions. But now they are outside of
EJB and I dont know if this functionality will be available.

If container do keep track of transactions like that then how many nested
levels I can go on? In one particular scenario, my EJB calls a method in a
class which in turn calls DAOs for Inserts/Updates/Deletes. Will they be
part of Container-managed Transactions as well?

It depends on the type of DB Connection you are using. If you have
configured your DataSource to provide you with XA-based Connections, or
if it does so automatically, then you should be fine. If not, then you
are not fine, and probably never have been. In particular, if you have
been using non-XA-based Connections with autocommit enabled then your DB
transactions have always been finer-grained than your J2EE transactions,
and you probably could not have correctly rolled back a J2EE transaction
even if you had wanted to do. (Though you might not have received any
exception.) You have a better chance of using non-XA Connections
correctly with bean-managed transactions, but even there you would want
to make sure that auto-commit was disabled, so that you could manually
ensure that JDBC transaction boundaries lined up with J2EE boundaries,
and that commit / rollback corresponded.

 

[Rizwan]

Thanks for reply.

It depends on the type of DB Connection you are using. If you have
configured your DataSource to provide you with XA-based Connections, or
if it does so automatically, then you should be fine.

How can I know if my DataSource is configured for XA-based Connections or
does so automatically? I am using JBOSS 3.2.

In my case I am working on now, only one JDBC connection (JNDI lookup) is
established for the whole transaction. The same connection is being used by
all concerned DAOs. The DAOs use this Connection to do their work but do not
perform any commit/rollback. That will be the responsibility of my logical
unit of work. So for example I have a method updateEmployee() in a class
which updates 3 different tables and return 1 for success and -1 for
failure:
public int updateEmployee( Map parameterMap )
This method is being called from my EJB. This will be the semantics of this
method:
* Get a new Connection (JNDI lookup);
* Build DAO Factory and set it to use the Connection I have;
* Build DAOs from the DAO Factory (these DAOs recieve the Connection from
the DAO Factory)
* Call 1st DAO's update method and get a return value.
* The return value is good. Call 2nd DAO's update method and get a return
value.
* The return value is not good. Now I want to rollback.

My question is how can I rollback or better should I issue a rollback for
the concerned connection or will the EJB takes care of it automatically?. If
I issue the rollback to the connection in DAO Factory then will my system
remain consistent with ACID?
Also if all 3 updates are good then should I issue a commit for the
concerned connection?

Thanks

 

[John C. Bollinger]

Thanks for reply.



How can I know if my DataSource is configured for XA-based Connections or
does so automatically? I am using JBOSS 3.2.

Look at it's configuration. It is probably configured per server (as
opposed to per application), though your application undoubtedly
declares a reference to it in its deployment descriptor. Frankly, it's
been a while since I mucked with JBoss configuration, but as I recall,
in the servers I worked with the configuration information for each
DataSource was in its own file in the server's filespace. I'm sorry I
can't be more specific. To interpret the configuration information, you
may also need documentation on the DB driver and/or some of the JBoss docs.

In my case I am working on now, only one JDBC connection (JNDI lookup) is

Do you mean that the Connection itself is stored and transferred via
JNDI? That sounds like a recipe for disaster. Please tell me it's not
what you meant. If your DAOs all want to use the same Connection
(probably a good idea) then you should pass them a Connection to use as
a parameter to each method that needs one. The normal role of JNDI in
this scheme is to provide access to a shared DataSource object that your
application uses to obtain Connections at need; I hope this is what you
mean you're doing.

established for the whole transaction. The same connection is being used by
all concerned DAOs. The DAOs use this Connection to do their work but do not
perform any commit/rollback.

Here, perhaps, is a point that you do not yet appreciate: it is quite
possible that your DAOs DO perform commits. This would happen on
execution of each statement if the Connection is in autocommit mode.
Now before you go running to turn off autocommit: don't. Mucking with
the autocommit mode of a Connection is not allowed in EJB; you need to
rely on the DataSource to give you correctly-configured Connections in
the first place.

That will be the responsibility of my logical
unit of work. So for example I have a method updateEmployee() in a class
which updates 3 different tables and return 1 for success and -1 for
failure:
public int updateEmployee( Map parameterMap )
This method is being called from my EJB. This will be the semantics of this
method:
* Get a new Connection (JNDI lookup);
* Build DAO Factory and set it to use the Connection I have;
* Build DAOs from the DAO Factory (these DAOs recieve the Connection from
the DAO Factory)

OK, so this is a viable alternative to passing a Connection to each DAO
method, though it does tie the Factory and all the DAO instances to a
single transaction context. That's not necessarily a big deal, as it
may fall out naturally that way anyway.

* Call 1st DAO's update method and get a return value.
* The return value is good. Call 2nd DAO's update method and get a return
value.
* The return value is not good. Now I want to rollback.

My question is how can I rollback or better should I issue a rollback for
the concerned connection or will the EJB takes care of it automatically?. If
I issue the rollback to the connection in DAO Factory then will my system
remain consistent with ACID?
Also if all 3 updates are good then should I issue a commit for the
concerned connection?

If you are using container-managed transactions (as you said you were),
then to ensure rollback you invoke the setRollbackOnly() method of the
bean's EJBContext. Supposing that you are using an XA Connection, it is
my understanding that EJB takes care of rolling back the DB transaction
upon exit from the transaction context, or for committing the DB
transaction if it has not been marked for rollback. This would be my
recommended mode of operation.