Hi Tausif,
after updating few records successfully, i get this exception:
ExceptionUtil E CNTR0019E: Non-application exception occurred while processing method "updateTransactionStatus". Exception data: com.ibm.websphere.csi.CSITransactionRolledbackException:
Not sure about the cause of this error... The only thing we can assume is:
As it is a
javax.transaction.TransactionRolledbackException (which is a system exception) your bean's method is called in the same transaction context as the calling method ( it is not me but
EJB 2.0 spec that defines such condition

):
<CallingBean's method runs in Tx1> --Tx1--> <YourBean's method runs in Tx1>
--Something unexpected in YourBean's method--> CallingBean's method gets TransactionRolledbackException
This suggests that
YourBean's method runs with
Required trans attribute
3. I replaced again my update statement, and uncommented my executeUpdate(sqlStmt).... failed... [censored] same prob, getting stuck...
One of the possible reasons could be the "application deadlock" that is not detectable by either your app server nor your database. Let me try to explain how it could happen.
Let's say you have got two methods (to make it more clear these methods are in different beans):
SessionBean1
<callingMethod>
SessionBean2
<executeUpdateMethod>
<executeUpdateMethod> runs with
RequiresNew transaction attribute.
Pseudocode for <callingMethod>, which runs in container transaction1
Pseudocode for <executeUpdateMethod>, which runs in container transaction2 as it has RequiresNew trans attribute
At the time when <callingMethod> called <SessionBean2#executeUpdateMethod> the container did not commit the results of [update <database_table_1>] operation into the database -> the database has X(exclusive) lock on the some part/all database_table_1. Because this method is run under "container transaction1" we can say that "container transaction1" has X(exclusive) lock on the some part/all database_table_1.
OK, now in <executeUpdateMethod> need to get S(shared) lock on some part/all database_table_1 in order to do [select from <database_table_1>]. Because running in "container transaction2" this method cannot get S(shared) lock till "container transaction1" releases X lock. However, "container transaction1" will not release this lock until method <SessionBean1#callingMethod> completes -> application hangs on <select> operation (application deadlock)
"Application deadlock" problem is something that
you should have in mind when debugging your particular problem.
Hope it helps ya a little.
