Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!
  • 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
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Understanding JTA internals

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ranchers,

I want to understand how JTA functions, especially:

1) I see a JTA implementation like a third-party service (or maybe independent server) to whom I tell to start/stop transaction (related to one or more DBs) for me. This service could even be called remotely (Like in the case of client initiated transaction in EJB). Is the analogy right ?

2) I take on another analogy: when I use an SQL client like sqlplus/Toad etc. I always have to commit on a particular connection, the connection I opened. So transaction delimitation is done by sending orders (commit/roolback) on the db connection. The same is the case when I use JDBC directly, I call connection.commit(). Must JTA - behind the scenes - also commit/rollback on one (ore more) connections ? Or is it totally different (sending start/stop on XAConnection is similar to me)

3) In a J2EE server, we retrieve a UserTransaction object an a DataSource object separately. We retrieve a Connection from the DataSource and delimit transactions by calling begin/commit/rollback on a totally different object: the UserTransaction instance. Behind the scenes, the TransactionManager will have to commit the work done on the Connection object I retrieved. How does the Transaction Manager know that I delimited the work on that Connection (i retrieved the 2 objects totally independently), i.e. how does the Transaction Manager link the Transaction with the Connection ? Is it because, behind the scenes, both the Connection object and the "Transaction" object are associated to the current Thread ? If Yes, and if I call EJB2 from EJB1 through local interfaces in a same transaction, does that mean that the call from EJB1 and then EJB2 have to run in the same thread ?

4) In the case of a client initiated transaction (in the EJB world), I can start a transaction from the client by using a Connection (issued from a DataSource I got through JNDI at location A) and a UserTransaction(I got also through JNDI but at location B). How does the JTA Transaction service know that it should send "delimitation" orders to the DB on the TCP DB Connection the server holds for my client app ? Remember that I got the UserTransaction and DataSource apparently with no relationship together ?

I have a lot of ideas how that could be done behing the scenes, but I want to know how a typical JTA service must/does this ?


Thanks in advance for your replies,

Regards,

Jean-Luc
 
Story like this gets better after being told a few times. Or maybe it's just a tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic