• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Question about transactions

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't have a lot of experience using Transactions but would like to learn more about the subject. I understand the ACID properties of transactions and the usefulness of demarcating blocks of code. What I really don't understand is the rollback facility which is the key benefit of using a transactional system.

Since transactions should be durable I am assuming the container will rollback the transaction if there is a server failure or similar situation that prevents the transaction from being committed. Right? The question is, how does the server know what resources and systems were affected and how to revert state? What if some actions are not possible to be rolled back?
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jim,


The question is, how does the server know what resources and systems were affected and how to revert state?


In a nutshell the transactions could be either global (distributed) or local. They could also be categorized as CMT or BMT, but from what I understand your question is related to CMT design. A local transaction implies that only one transactional system is involved, like a database. In this case the transaction manager�s job is very easy: it only needs to commit and rollback the transaction for that dbms. At a lower level the container uses the jTS/JTA api that needs how to take care of this task. When more than a transactional system is involved, like a jms service along with a database, or multiple databases, then the container implements the 2PC protocol. In a nutshell the transaction coordinator will commit/rollback the global transaction in two steps:
  • All participants will notify the transaction coordinator whether they can commit the transaction or not.
  • The transaction coordinator decides whether to commit or rollback the transaction. If all participants have been voted to commit, the global transaction will be finally committed. Otherwise the distributed transaction is rolled back.



  • What if some actions are not possible to be rolled back?


    That�s not an option. Every transactional system must be able to commit and rollback transactions accordingly. You should always presume that an action is not rolled back either because you're not changing a transactional system, either the action is not executed within a transactional context, or the transaction demarcation is not properly designed, etc.
    Regards.
     
    Yeah. What he said. Totally. Wait. What? Sorry, I was looking at this tiny ad:
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
      Bookmark Topic Watch Topic
    • New Topic