• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

BMT transactions question

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This pertains to the text on pg.486 of HFE regarding BMT transactions participants calling setRollBackOnly instead of rollback.I missed the point-
about why it should proceed at all..? Can someone explain?
 
cowbird
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess calling setRollbackOnly() instead of rollback() is in some cases 'cleaner' programming. Suppose A starts a tx, calls B for doing some work propagating the tx, then A continous, maybe calling C and D, to either commit or rollback at the end of the ride.

If you're programming B, you know that you will be called with an incoming tx, but you don't know what's happening before or after you. IMHO, it's nicer and cleaner for B to not rollback the tx, but instead mark it for rollback (call setRollbackOnly()). It's B's responsability to decide wether his part went wrong and should be rolled back, but it's A's decision to oversee the whole process, and do the actual rollback, based on what the called methods/beans/components did...

You could imagine a process (method) for A that calls B, then B marks the tx for rollback and returns, A checks the rollback-status, and (maybe at the end) calls C to log that something went wrong ... or something. :roll:

When using this technique, you should really make sure that A doesn't do a lot of work when the tx is already marked for rollback. So use getStatus() to check this before doing something that could use sparse resources when the tx is already doomed!

Greetz, Jef
[ August 10, 2004: Message edited by: Jef Cumps ]
 
Anirudh Borkar
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That makes sense; I got stumped because in my mind, A(which initiated the tx) encountered a condition which justified rolling back - why would it proceed with calling other methods when it knows right away and can make that decision.You clarified it though; the provision seems to be for scenarios where such conditions are encountered by other beans which are called.

Thanks!
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Anirudh Borkar:
This pertains to the text on pg.486 of HFE regarding BMT transactions participants calling setRollBackOnly instead of rollback.I missed the point-
about why it should proceed at all..? Can someone explain?



The reason given here was that the typical scenario where you could use the rollback method is at the end of the method, depending if things look good (and in this case you'd commit) or look bad (and in this case you'd rollback). But the above scenario would normally happen at the end of a method. On the other side, if you know that your transaction is going to end badly, and because BMT transaction can propagate their transaction context to other CMT beans (not vice-versa), and CMT beans can check the transaction status via getRollbackOnly method, then you have a possibility of being a *good* network citizen, giving a chance to other *good* network citizens to shorten a failing process, thus increasing performance.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic