Bridging Transactions from Java EE to .NET

1,479 views

Published on

JavaOne 2010, Session ID: S314687

Cross-platform transactions between enterprise Java and .NET should be easy, right? After all, both platforms have implemented the same specification. How hard can it be? This session will attempt to answer that question by providing an in depth look at distributed transactions including implementations in enterprise Java and .NET. Technologies that provide cross-platform transactions will be demoed providing a look at code from examples using WS-AT/WS-Coor and direct bridging using a shared-memory JVM-to-CLR implementation. In closing, the session will discuss performance benchmarking, “gotchas”, tips and tricks and the move towards eXtreme Transaction Processing and what that means for current Java EE and .NET based technologies.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,479
On SlideShare
0
From Embeds
0
Number of Embeds
235
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Bridging Transactions from Java EE to .NET

  1. 1. Bridging Transactions from Java EE to .NET Bill Heinzman JNBridge, LLC www.jnbridge.com
  2. 2. Agenda <ul><li>A brief introduction to 2PC </li></ul><ul><li>How the Java RM does it </li></ul><ul><li>How the .NET RM does it </li></ul><ul><li>Why cross platform transactions are hard </li></ul><ul><li>Attempts at solving the problem </li></ul><ul><li>Bridging: Keep it simple </li></ul><ul><li>The Future </li></ul>Copyright © 2010 JNBridge, LLC Slide
  3. 3. Two Phase Commit Transactions <ul><li>Distributed protocol among multiple resources </li></ul><ul><li>Requirements—ACID </li></ul><ul><ul><li>Among discreet, or a tomic resources (all or nothing) </li></ul></ul><ul><ul><li>A transaction is what causes resources to move between c onsistent states </li></ul></ul><ul><ul><li>A resource is i solated during a transaction </li></ul></ul><ul><ul><li>The state of a resource after a transaction is d urable, i.e. persistent </li></ul></ul><ul><li>Two phase commit transactions </li></ul><ul><ul><li>Degenerate case—one resource is single phase </li></ul></ul><ul><ul><li>Committee process with a coordinator </li></ul></ul>Copyright © 2010 JNBridge, LLC Slide
  4. 4. Two Phase Commit Transactions <ul><li>2PC </li></ul><ul><ul><li>Commit-request phase—voting phase </li></ul></ul><ul><ul><li>Commit phase </li></ul></ul><ul><li>Implementation specification: The Open Group's XA </li></ul><ul><ul><li>Architecture and a… </li></ul></ul><ul><ul><li>Protocol </li></ul></ul><ul><li>Resource managers coordinate with the transaction so the application doesn’t have to. </li></ul>Copyright © 2010 JNBridge, LLC Slide Application Resource Managers Transaction
  5. 5. Two different sons of the same mother <ul><li>Both Java and .NET implemented the same architecture </li></ul><ul><ul><li>Similar semantics, slight differences in protocol </li></ul></ul><ul><li>Java RM Interface—XAResource </li></ul><ul><ul><li>start(): Called first after RM is enlisted with current transaction </li></ul></ul><ul><ul><li>end(): Called next—means there’s a quorum and it’s time to vote. Also means all the work is done with no exceptions, because if there was, the transaction would just “short circuit” and call rollback(). </li></ul></ul><ul><ul><li>prepare(): The vote. This blocks—worth repeating—this blocks! </li></ul></ul><ul><ul><ul><li>What’s the timeout on the transaction? </li></ul></ul></ul><ul><ul><li>commit(): unanimous consensus from voting </li></ul></ul><ul><ul><li>rollback(): somebody said no! </li></ul></ul>Copyright © 2010 JNBridge, LLC Slide
  6. 6. Two different sons of the same mother <ul><li>.NET RM Interface—IEnlistmentNotification </li></ul><ul><ul><li>Prepare(): Same semantics as Java; blocks too. </li></ul></ul><ul><ul><ul><li>Timeouts, again. </li></ul></ul></ul><ul><ul><li>Commit(): The same as Java. </li></ul></ul><ul><ul><li>Rollback(): Ditto. </li></ul></ul><ul><li>Try again protocol…….or not. </li></ul><ul><ul><li>Transaction manager gets into the act. </li></ul></ul><ul><ul><li>Java: forget(), recover(). .NET: InDoubt(). </li></ul></ul><ul><ul><ul><li>The RM must save a log before prepare() or, for .NET, when InDoubt() is called. </li></ul></ul></ul><ul><ul><ul><li>Transaction branches. </li></ul></ul></ul>Copyright © 2010 JNBridge, LLC Slide
  7. 7. Some observations. <ul><li>Java </li></ul><ul><ul><li>“ Busier” implementation </li></ul></ul><ul><ul><li>RM must handle multiple heuristic branches using a Xid token that consists of a transaction ID and a “branch” ID. </li></ul></ul><ul><li>.NET </li></ul><ul><ul><li>Very simple, just the minimum to get the job done. </li></ul></ul><ul><li>However, both .NET and Java seem to have implemented the same specification—looks pretty simple, like two dialects of the same language. </li></ul><ul><ul><li>So why are cross platform transactions so difficult to implement and use? </li></ul></ul>Copyright © 2010 JNBridge, LLC Slide
  8. 8. “ Boil the ocean” <ul><li>Distributed, global, multi-parallel universal transactions </li></ul><ul><ul><li>Trying to solve the unnecessary case. </li></ul></ul><ul><li>Transaction Managers </li></ul><ul><ul><li>Coordinate among themselves. Yet another standard—OSI TP. </li></ul></ul><ul><ul><li>Java TMs and .NET TMs don’t play well with each other. </li></ul></ul><ul><li>The 2PC protocol is an inherently blocking protocol that doesn’t scale well increasing both latency, complexity and failure rate. </li></ul><ul><li>Work done to address these problems. </li></ul><ul><ul><li>Presumed commit and rollback—limit messages between TMs. </li></ul></ul><ul><ul><li>Tree 2-phase commit—walk the distributed resources in network order. </li></ul></ul><ul><ul><li>Dynamic 2PC—Coalesce, or collapse to a single TM node. </li></ul></ul>Copyright © 2010 JNBridge, LLC Slide
  9. 9. Attempts at cross-platform transactions <ul><li>Transaction Internet Protocol (TIP) </li></ul><ul><ul><li>Defunct </li></ul></ul><ul><li>WS-Atomic/WS-Coord </li></ul><ul><ul><li>Web services based, poor performance. </li></ul></ul><ul><ul><li>Difficult, if not impossible, to implement. </li></ul></ul><ul><ul><li>Actually have never met anybody who’s gotten it to work. </li></ul></ul><ul><li>Database transactions are very interoperable, however not much else is. </li></ul><ul><ul><li>Messaging, JMS or MSMQ. </li></ul></ul>Copyright © 2010 JNBridge, LLC Slide
  10. 10. Cross-platform transaction bridging <ul><li>Cross-platform transaction bridging using tightly coupled interoperability. </li></ul><ul><ul><li>Integrate active transactions on .NET and Java sides </li></ul></ul><ul><ul><ul><li>Let the TMs reside in their sandbox, don’t get them involved. </li></ul></ul></ul><ul><ul><ul><li>Back to using the simple RM/Transaction protocol. </li></ul></ul></ul><ul><ul><ul><li>Cross-platform transaction integration is mostly transparent to user. </li></ul></ul></ul><ul><ul><ul><li>Rollback on either side will cause actions on both sides to be rolled back. </li></ul></ul></ul><ul><ul><ul><li>Commit on both sides will cause both sides to be committed. </li></ul></ul></ul><ul><ul><li>Provide for the common case. </li></ul></ul><ul><ul><li>Works with all vendors’ JEE implementations </li></ul></ul>Copyright © 2010 JNBridge, LLC Slide
  11. 11. Cross-platform transaction bridging Copyright © 2010 JNBridge, LLC Slide
  12. 12. Transaction future <ul><li>It’s not about how many distributed resources you can group into a global transaction, it’s how many transactions can you do in a second. </li></ul><ul><ul><li>Each transaction has at most two resources. </li></ul></ul><ul><ul><li>Xtreme transaction processing. </li></ul></ul><ul><li>The cloud thing </li></ul><ul><ul><li>Transactions in the cloud must be an abstract resource managed by the cloud. </li></ul></ul><ul><ul><li>Transactions between the cloud and the ground must be truly interoperable and transparent. </li></ul></ul>Copyright © 2010 JNBridge, LLC Slide
  13. 13. Thank You! <ul><li>Contact info: Bill Heinzman [email_address] 303.545.9371 www.jnbridge.com </li></ul>Copyright © 2010 JNBridge, LLC Slide Slide

×