We are using Weblogic 7 and I have a question about transaction-handling. In one of our MessageDrivenBeans (container-transaction) we 1.) modify some EntityBeans (container-transaction) and 2.) have to call some SQL via JDBC (currently in its own transaction) to update some data-relations. Problems occur when the MessageDrivenBean-transaction is rolled-back for any reason and the lines invoking the JDBC-Calls has already been executed and successfully commited to the DB. We need a solution which ensures that both CMP and JDBC-SQL operations are rolled-back in case of an error (like in one transaction).

The following two solution I thought about:

1. - Using CMR instead of SQL via JDBC, but this is not an option in my company.
2. - Using the actual Container-Tranaction (from the MessageDrivenBean) to do my JDBC-SQL.

How is such a scenario (CMP + JDBC within one transaction) generally handled in an EJB-Environment ?

Even if not best practise, how can I programmatically access the actual Container-Transaction and use this for my own JDBC-SQL operation, when this is possible at all ?

Thanks in advance.

Transaction contexts:
MessageDrivenBean -> RequiresNew
   EntityBean -> Required
   Perform SQL operations

Your entity bean and SQL are automatically encapsulated in your message driven bean's transaction context. (This is all under CMT ofcourse)

Using CMR implies, you create an entity bean instead of SQL and JDBC. I cannot comment on it with the current input.

we 1.) modify some EntityBeans (container-transaction) and 2.) have to call some SQL via JDBC (currently in its own transaction) to update some data-relations. Problems occur when the MessageDrivenBean-transaction is rolled-back for any reason and the lines invoking the JDBC-Calls has already been executed and successfully commited to the DB. We need a solution which ensures that both CMP and JDBC-SQL operations are rolled-back in case of an error (like in one transaction).

>2.) have to call some SQL via JDBC (currently in its own transaction) to update some data-relations.

For the 2nd step make sure that you obtain the connection from the same data source to which the entity bean is mapped. Also ensure that updates in the entity bean happen within the transaction context of the message drive bean (i,e entity bean update does NOT start a new transaction). You will get the desired result.

Regards
Kingshuk