• Post Reply Bookmark Topic Watch Topic
  • New Topic

auto commit within JTS transaction  RSS feed

 
Tausif Khanooni
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alex,

(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
 
Tausif Khanooni
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all,
please reply to this msg.. ignore the other one with the same subject.... i m not able to see any msg test in my earlier thread

thanks again
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!