On Rollback in EJB,How to perform some function

[Raj Jindal]

In my EJB bean, I am executing a sequence of sql statements in block. ie in same transaction. If any of the SQL gets failed, the exception will occur.
1. How can i rollback the transaction.
2. On rollback, If i want to perform some function, where will i be writing the logic for that.
e.g:- when exception occurs, control goes to catch bloc. should i write rollback in catch block. If yes, should i also write the logic to perform something extra operation on rollback, also in catch block.

[Viswanatha GB]

Hi, I think you need to understand first few thigns on EJB transaction.

1. Read about ACID : Basic properties of transactions can be summarized using the ACID mnemonic:
2. Transaction Attributes
Transactions can be defined at several different levels and in several different ways.
- Levels
3. Isolation Levels : Isolation levels provide a degree of control of the effects one transaction can have on another.
Then how to
Implementing Two-Phase Commits...
I asume you are using some Application server before telling all the above..
any way if you uise any vendor Application server like IBM WSAD, BEA Weblogic.
Life makes simple...for your problem...
Here goes...how
In the Session EJB method, enclose the statement(s) that start the thread that eventually reaches the operations on multiple EJBs within a try-catch block; e.g.,
try {
return domain.updateBoth( DataBean dataBean);
} catch ( Exception e ) {
mySessionCtx.setRollbackOnly();
}
Note: mySessionCtx is a global variable that is generated by WSAD and included in the Session EJB.

I hope this helps you..
Viswa

[David Harkness]

Originally posted by raj jindal:
In my EJB bean, I am executing a sequence of sql statements in block. ie in same transaction. If any of the SQL gets failed, the exception will occur.
1. How can i rollback the transaction.

This depends on whether your using container-managed transactions (CMT) or bean-managed transactions (BMT). In CMT, you inform the contain that it should rollback the current transaction once it ends. It ends when it returns from a method that started it. If you're using BMT, you rollback the transaction itself using UserTransaction's (obtain via JNDI) rollback() method.

Originally posted by raj jindal:
2. On rollback, If i want to perform some function, where will i be writing the logic for that.

This depends more upon what you need to do (is it transactional?) and the patterns you're using. With BMT, since you're explicitly starting and ending the transaction yourself, it's easiest to do your extra rollback operations when you actually roll the transaction back.
Here's some skeleton code. Note that it doesn't catch all the exceptions thrown by methods like lookup(), begin(), etc.

// Acquire javax.transaction.UserTransaction
UserTransaction txn = ctx.lookup("javax.transaction.UserTransaction");
// Start transaction
txn.begin();
try
{
  // Do the work
  // ...
  
  // Commit transaction
  txn.commit();
}
catch ( Exception e )
{
  // Rollback transaction
  txn.rollback();
  
  // Do cleanup work
  // ...
}

If you're using CMT, you'd remove all the txn.foo() calls (and everything related to txn), except that you'd *replace* "txn.rollback()" with "sessionContext.setRollbackOnly()".

[Ken Boyd]

 
// Acquire javax.transaction.UserTransaction
UserTransaction txn = ctx.lookup("javax.transaction.UserTransaction");
// Start transaction
txn.begin();
try
{
// Do the work
// ...
// Commit transaction
txn.commit();
}
catch ( Exception e )
{
// Rollback transaction
txn.rollback();

// ...
}
------Added NEW LINE-----------
  if (ut.getStatus()){
    // Do work according to status
   } else {
    // Do work according to status
   }
------Added NEW LINE-----------
 

Just adding something extra to above reply.
Hope this help.

[Patrick Nolan]

Perhaps you should consider using CMP entity beans for your create, update, delete operations. This will give you container-managed transactions, which really makes life easier for these operations. (On a side note, I implement read operations using straight JDBC because it is so much faster - at least with 9ias. But for create, update, delete I take advantage of the container transaction services). In your ejb deployment descriptor (ejb-jar.xml), use the <trans-attribute> to set the type of transactional behavior. Setting this to "Required" for all methods involved in your transaction will give you the "if one fails, all fail" behavior. Like the previous poster mentioned, read up on ACID.
Patrick J. Nolan, Jr.