Bridging Transactions from Java EE to .NET

Bridging Transactions from Java EE to .NET Bill Heinzman JNBridge, LLC www.jnbridge.com

Agenda
A brief introduction to 2PC
How the Java RM does it
How the .NET RM does it
Why cross platform transactions are hard
Attempts at solving the problem
Bridging: Keep it simple
The Future
Copyright © 2010 JNBridge, LLC Slide

Two Phase Commit Transactions
Distributed protocol among multiple resources
Requirements—ACID
Among discreet, or a tomic resources (all or nothing)
A transaction is what causes resources to move between c onsistent states
A resource is i solated during a transaction
The state of a resource after a transaction is d urable, i.e. persistent
Two phase commit transactions
Degenerate case—one resource is single phase
Committee process with a coordinator

Two Phase Commit Transactions
2PC
Commit-request phase—voting phase
Commit phase
Implementation specification: The Open Group's XA
Architecture and a…
Protocol
Resource managers coordinate with the transaction so the application doesn’t have to.
Copyright © 2010 JNBridge, LLC Slide Application Resource Managers Transaction

Two different sons of the same mother
Both Java and .NET implemented the same architecture
Similar semantics, slight differences in protocol
Java RM Interface—XAResource
start(): Called first after RM is enlisted with current transaction
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().
prepare(): The vote. This blocks—worth repeating—this blocks!
What’s the timeout on the transaction?
commit(): unanimous consensus from voting
rollback(): somebody said no!

Two different sons of the same mother
.NET RM Interface—IEnlistmentNotification
Prepare(): Same semantics as Java; blocks too.
Timeouts, again.
Commit(): The same as Java.
Rollback(): Ditto.
Try again protocol…….or not.
Transaction manager gets into the act.
Java: forget(), recover(). .NET: InDoubt().
The RM must save a log before prepare() or, for .NET, when InDoubt() is called.
Transaction branches.

Some observations.
Java
“ Busier” implementation
RM must handle multiple heuristic branches using a Xid token that consists of a transaction ID and a “branch” ID.
.NET
Very simple, just the minimum to get the job done.
However, both .NET and Java seem to have implemented the same specification—looks pretty simple, like two dialects of the same language.
So why are cross platform transactions so difficult to implement and use?

“ Boil the ocean”
Distributed, global, multi-parallel universal transactions
Trying to solve the unnecessary case.
Transaction Managers
Coordinate among themselves. Yet another standard—OSI TP.
Java TMs and .NET TMs don’t play well with each other.
The 2PC protocol is an inherently blocking protocol that doesn’t scale well increasing both latency, complexity and failure rate.
Work done to address these problems.
Presumed commit and rollback—limit messages between TMs.
Tree 2-phase commit—walk the distributed resources in network order.
Dynamic 2PC—Coalesce, or collapse to a single TM node.

Attempts at cross-platform transactions
Transaction Internet Protocol (TIP)
Defunct
WS-Atomic/WS-Coord
Web services based, poor performance.
Difficult, if not impossible, to implement.
Actually have never met anybody who’s gotten it to work.
Database transactions are very interoperable, however not much else is.
Messaging, JMS or MSMQ.

Cross-platform transaction bridging
Cross-platform transaction bridging using tightly coupled interoperability.
Integrate active transactions on .NET and Java sides
Let the TMs reside in their sandbox, don’t get them involved.
Back to using the simple RM/Transaction protocol.
Cross-platform transaction integration is mostly transparent to user.
Rollback on either side will cause actions on both sides to be rolled back.
Commit on both sides will cause both sides to be committed.
Provide for the common case.
Works with all vendors’ JEE implementations

Transaction future
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.
Each transaction has at most two resources.
Xtreme transaction processing.
The cloud thing
Transactions in the cloud must be an abstract resource managed by the cloud.
Transactions between the cloud and the ground must be truly interoperable and transparent.

Bridging Transactions from Java EE to .NET

by JNBridge on Sep 28, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 141

Statistics

Bridging Transactions from Java EE to .NET — Presentation Transcript