Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question about CMT transactions

 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

what happens if I've got a CMT slsb which runs a business method in a 'Required' transaction and this method invokes a method on an ordinary Java class? I mean, if the method in the ordinary Java class uses CMT entity beans to write some records to the database, and the process breaks for some reason, I throw a checked exception, which gets catched by the slsb (the original caller), where I set sessionContent.setRollbackOnly() and re-throw the exception so that it gets propagated to the container. Is the transaction rolled back? Is the situation in the database as the original method on the slsb was never called?

Thanks for any answer,

Marco
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Whenever you call setRollbackOnly() on the SessionContext, the Container MUST roll back the transaction (17.6.2.8). I don't know if this answers your question. Please don't hesitate otherwise
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Valentin Crettaz:
Whenever you call setRollbackOnly() on the SessionContext, the Container MUST roll back the transaction (17.6.2.8). I don't know if this answers your question. Please don't hesitate otherwise



I know it but my doubts are related to the following scenario:

slsb.methodA() --> Starts Tx1
memthodA() --> Invokes PlainJavaClass.method1(); (Does this run in Tx1 transaction?)
PlainJavaClass.method1() --> Updates DB through entity bean --> Still Tx1?

What happens if PlainJavaClass.method1() fails in the middle of its execution (let's say it updated 10 records through entity beans)?

Thanks,

Marco
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK I see! Actually, if the bean calls a method on a POJO and something happens in that POJO, the exception will percolate up the call stack until it reaches the container. At that time, the container won't make a difference whether the exception was thrown in a bean or in a POJO. What matters is that an exception has been thrown and that the container gets to know it through the bean which happens to run within a transaction.

Does this make sense?
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Valentin Crettaz:
OK I see! Actually, if the bean calls a method on a POJO and something happens in that POJO, the exception will percolate up the call stack until it reaches the container. At that time, the container won't make a difference whether the exception was thrown in a bean or in a POJO. What matters is that an exception has been thrown and that the container gets to know it through the bean which happens to run within a transaction.

Does this make sense?


Sorry, but I still didn't understand if the records updated in the meantime are rolled back or not.
 
Severin Stoeckli
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marco, it's like the following


slsb.methodA() --> Starts Tx1 => yes

memthodA() --> Invokes PlainJavaClass.method1(); (Does this run in Tx1 transaction?) => yes, this run in Tx1
PlainJavaClass.method1() --> Updates DB through entity bean --> Still Tx1? depends on the transaction attribute of your entity bean, eg. RequiresNew no, Required yes

==> it depends on the transaction attribute of your entity bean method if the transaction is rolled back or commited!

Severin
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Severin St�ckli:
Marco, it's like the following


slsb.methodA() --> Starts Tx1 => yes

memthodA() --> Invokes PlainJavaClass.method1(); (Does this run in Tx1 transaction?) => yes, this run in Tx1
PlainJavaClass.method1() --> Updates DB through entity bean --> Still Tx1? depends on the transaction attribute of your entity bean, eg. RequiresNew no, Required yes

==> it depends on the transaction attribute of your entity bean method if the transaction is rolled back or commited!

Severin


Got it now!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic