Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Transactions: How Distributed Are Yours?

Talk to your peers

Another discussion based on a weblogic.developer.interest.transaction posting this month. It's a newsgroup that always proves to be a good source of information for the world at large when it comes to transactional behavior (and a good source of inspiration for me when the article time of the month rolls around again).

This particular posting is a great illustration of how an apparently simple assumption can pitch you into the bowels of the infrastructure, if you're not carefully guided by the architecture you're building against, and the possibilities it offers. The original posting ran:

We have to use distributed transactions between an XADataSource configured at the Web tier level in Tomcat 4.1.27 and an XADataSource configured in WebLogic Server 8.1. As a proof of concept, I built a small servlet sample that uses the XADataSource in Tomcat and uses the transaction manager of WebLogic.

When enlisting the XAResource with the javax.transaction.Transaction object, I keep receiving the following exception:

javax.transaction.SystemException: Not implemented at
weblogic.corba.j2ee.transaction.TransactionManagerImpl.enlistResource
(TransactionManagerImpl.java:370)
at com.myco.jta.TestServlet.addSubscription(TestServlet.java:103)
at com.myco.jta.TestServlet.doGet(TestServlet.java:46)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

We use XAPool from ObjectWeb as the XADataSource implementation. I'd like to know if we are using JTA properly and if we are missing a configuration of some sort at the WebLogic level.

On the face of it, what could be simpler: a distributed architecture, and we want distributed transactions so let's start coding... But these exceptions quickly put a stop to that, and give pause for thought... Let's think this through.

A first observation, at a high level (and at a tangent to the whole point of this article), is the implicit physical splitting of tiers in this posting. Okay, there may be very good reasons in this case why Tomcat is used for the JSP/servlet logic - maybe it's already in production and is being extended - but WebLogic has a perfectly good servlet/JSP capability. It is amazing how many people decide that the fact that Sun describes a Web tier and an EJB tier means that these tiers must be physically separate. Even people using WebLogic for both the Web tier and the EJB tier often decide that they should deploy different WebLogic instances for both. This is not necessarily the case. Calling between processes is costly and a source of complexity in development, configuration management, and production maintenance. Yes, you can make the tiers physically separate, but even if all the tiers are deployed in a single WebLogic instance they are no less logically distinct! Sorry about that rant, this is a subject that really gets my goat. Just be thankful that I fought the temptation to type the whole of this paragraph in bold caps!

That Really Gets My Goat!
So, Ommmmm... Calm, calm, calm... and back to the plot.

At the high level, transactions flow around our J2EE system quite transparently; you start them, make calls, commit them, and take it for granted that the transaction context flowed around with your calls, and the commit processing touched all the resources you ended up using. This sounds like magic, and - of course - like everything else in the world, it isn't. There is a rational explanation. To find it, you just need to look beneath the J2EE surface you're coding to. What happened under the covers is that every time you made a call, the runtime discovered a Transaction object associated with your thread. This discovery prompted the runtime to piggyback the data about the transaction with the request. The piggybacked transaction information has, in turn, caused the infrastructure on the receiving end to do the "right thing" in terms of associating a transaction with its thread of control, and piggybacked data about the resources that got touched to make sure all the bits of transaction know about each other, so when the time comes the transaction co-ordinator can wander by, tell all the resources (which it has collected a list of) to commit, and life is good. All this apparent magic is wonderful, but it does imply a pretty close coupling between the application server's runtime infrastructure and the transaction manager, and this implication is not for nothing - the two are pretty inextricably tied together. So when you start talking about the scenario laid out in the newsgroup, where two different infrastructure implementations are involved, things are going to get a bit hairy if you carry on trying to make the simple assumption that transactions will flow between the containers and "just work" when it comes to commit time.

What it boils down to is that BEA WebLogic cannot make any assumptions about the nature of a client that is calling it but, as I discussed way back in November 2002 (WLDJ, Vol. 1, issue 11), it tries to smooth over the cracks by allowing a client to demarcate transactions whose completion will be delegated to a server-side transaction manager. A Tomcat client is no exception to that; as far as WebLogic is concerned, it is every bit as incapable as an applet.

What's Needed Is a Peer Relationship
What's needed to flow transactions between implementations in the way that the original poster wanted is a peer relationship between them, not a client/server one. If the two containers can be confident that each can look after itself in terms of transaction logging and recovery, then all that is needed is a shared understanding of how the transactions in one environment map on to those in the other. One way of doing this is via RMI/IIOP. If the containers are both speaking that protocol (as they are mandated to be able to do by J2EE 1.3) then the CORBA OTS specification provides a standard mechanism and interfaces for the transactions to flow through. Each container can handle its own internal implementation, with OTS providing a gateway between them. Internally to WebLogic, this gateway is implemented via a concept called an "Interposed Transaction Manager" - if WebLogic needs to import a transaction via OTS, that actually entails listening for "prepare", "commit", and "rollback" instructions from the remote system and responding appropriately to them. The BEA WebLogic transaction manager simply sits between these instructions and the actual resources participating in the transaction on the WebLogic side - it is interposed between the TM that controls the transaction and the local resources that it manages. If you think about it, responding to begin/prepare/commit/abort commands is exactly what any resource manager does through the xa interface. Wouldn't it be a neat trick if an xa interface could be exposed to WebLogic's transaction manager; then any foreign transaction manager could propagate transactions into WebLogic via xa, as if it were a database or any other xa resource, irrespective of support for any given network protocol.

The good news is that WebLogic's transaction manager offers just such a capability via the getServerInterposedTransactionManager and getClientInterposedTransactionManager methods provided by the weblogic.transaction.TxHelper. These methods give you the ability to get pretty exotic with the propagation of transactions into and out of WebLogic, to help you stitch together the end-to-end propagation of transactions.

As for the bad news... Well, until Tomcat grows a transaction manager of its own as a peer to WebLogic's, the scenario we started from just isn't going to work. Not that that's necessarily a bad thing - client code demarcating transactions can get some transaction architects foaming at the mouth and ranting, but that's a story for another month!

More Stories By Peter Holditch

Peter Holditch is a senior presales engineer in the UK for Azul Systems. Prior to joining Azul he spent nine years at BEA systems, going from being one of their first Professional Services consultants in Europe and finishing up as a principal presales engineer. He has an R&D background (originally having worked on BEA's Tuxedo product) and his technical interests are in high-throughput transaction systems. "Of the pitch" Peter likes to brew beer, build furniture, and undertake other ludicrously ambitious projects - but (generally) not all at the same time!

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Druva is the global leader in Cloud Data Protection and Management, delivering the industry's first data management-as-a-service solution that aggregates data from endpoints, servers and cloud applications and leverages the public cloud to offer a single pane of glass to enable data protection, governance and intelligence-dramatically increasing the availability and visibility of business critical information, while reducing the risk, cost and complexity of managing and protecting it. Druva's...
BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
DSR is a supplier of project management, consultancy services and IT solutions that increase effectiveness of a company's operations in the production sector. The company combines in-depth knowledge of international companies with expert knowledge utilising IT tools that support manufacturing and distribution processes. DSR ensures optimization and integration of internal processes which is necessary for companies to grow rapidly. The rapid growth is possible thanks, to specialized services an...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...