Bridging Transactions from Java EE to .NET

Bridging Transactions from Java EE to .NET

Bill HeinzmanJNBridge, LLC

www.jnbridge.com

Copyright © 2010 JNBridge, LLCSlide 2

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


Two Phase Commit Transactions

● Distributed protocol among multiple resources● Requirements—ACID

• Among discreet, or atomic resources (all or nothing)

• A transaction is what causes resources to move between consistent states

• A resource is isolated during a transaction

• The state of a resource after a transaction is durable, 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.

Application

ResourceManagers

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

Copyright © 2010 JNBridge, LLC

Cross-platform transaction bridging

Slide 11


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.

Copyright © 2010 JNBridge, LLCSlide 13Slide 13

Thank You!

● Contact info:

Bill Heinzman

[email protected]

www.jnbridge.com

mailto:[email protected]

Date post:	14-Jun-2015
Category:	Technology
Upload:	jnbridge
View:	1,226 times
Download:	2 times

Bridging Transactions from Java EE to .NET

Technology