auto commit within JTS transaction
Tausif Khanooni
Ranch Hand
Posts: 107
posted 13 years ago
Hi Alex,
(other message got deteleted accedently, so i m posting it again here)
Thnx for your reply dude...
Yea, you got me 100% right... that is what exactly i have the entry in my ejb-jar.xml...
I dont know whether i got u properly or not (i.e.... from the table which does not get updated), but what i did i tell u..
1. as u said, I commented my executeUpdate(sqlStmt) (the one which was stopping my execution) and just simply had a SELECT statement at a temp table... WORKD FINE...
2. then I did a SELECT query on the same table which i want to update, WORKD FINE
now the climex begin
3. I replaced again my update statement, and uncommented my executeUpdate(sqlStmt).... failed...
same prob, getting stuck...
tell me what should i do??
more over one more prob i have, for now, i m keeping my entry "RequiresNew" for all methods (say have <method-name>*</method-name>
in ejb-jar.xml
after updating few records successfully, i get this exception:
help me please
thnx in advance
(other message got deteleted accedently, so i m posting it again here)
Thnx for your reply dude...
If I understood you correctly, you're saying that
Yea, you got me 100% right... that is what exactly i have the entry in my ejb-jar.xml...
In order to debug I'd do the following (with your method set to RequiresNew while all other methods have Required):
1. Rather than executing an update statement do a simple sql select from the table that does not get updated
I dont know whether i got u properly or not (i.e.... from the table which does not get updated), but what i did i tell u..
1. as u said, I commented my executeUpdate(sqlStmt) (the one which was stopping my execution) and just simply had a SELECT statement at a temp table... WORKD FINE...
2. then I did a SELECT query on the same table which i want to update, WORKD FINE
now the climex begin
3. I replaced again my update statement, and uncommented my executeUpdate(sqlStmt).... failed...
same prob, getting stuck...tell me what should i do??
more over one more prob i have, for now, i m keeping my entry "RequiresNew" for all methods (say have <method-name>*</method-name>
in ejb-jar.xml after updating few records successfully, i get this exception:
help me please
thnx in advance
"Walking on water and building IT Architecture from <br />specification are easy if and only if both are frozen"
Tausif Khanooni
Ranch Hand
Posts: 107
Alex Sharkoff
Ranch Hand
Posts: 209
posted 13 years ago
Hi Tausif,
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
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.
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.
Alex (SCJP 1.4, SCBCD 1.3, SCWCD 1.4, SCJD 1.4)
