Welcome!

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

Related Topics: Weblogic

Weblogic: Article

Transactions and Beans:Why have a dog and bark yourself?

Transactions and Beans:Why have a dog and bark yourself?

That was what an old girlfriend periodically said to me. Needless to say, we're no longer together - I wasn't keen on the comparison. "Shall I compare thee to a dog?" is rather less poetic than I like. But in thinking about this month's transaction column, the comment seemed strangely germane to the world of app servers and transactions.

I've mentioned several times in these articles that the underlying purpose of an application server is to provide out-of-the-box functionality that you would otherwise have to write and maintain yourself, despite it having only indirect relevance to the business problem at hand. For example, "Transfer money from my current account to my savings account" is an operation that any banker would comprehend. "Implement a two-phase commit transaction manager" would probably leave them dazed and confused, despite the implicit requirement for an atomic transfer of funds.

Bankers never seem keen on creating money (unless it's created in their pockets) or making it vanish (unless it vanishes from your pocket and reappears in theirs). With this in mind, the wise developer buys an app server and uses its JTA transaction manager to provide the necessary atomicity guarantees underlying the business operation, while the unwise (and shortly to be unemployed) one goes off on a two-year mission to implement transaction services, because it's fun to do.

I'll Be Your Dog
So, it's clear that we don't want to waste our lives (and risk our jobs) by writing a transaction manager. Wouldn't it be great if we could go one step further and not write a single line of code about transactions and have them magically handled by the infrastructure? Not only would that mean fewer lines of code to understand and maintain, but it would guarantee that all our code made a consistent set of assumptions about the transactional semantics of the application. This would, in turn, make reusing the application componentry much easier without having to go back to the design docs (or worse, the code) and decipher what the underlying intentions and assumptions were.

Happily, they thought of all that when J2EE was invented, and the EJB container is equipped not only to manage persistence and security, but transactions too. In fact, not only is it equipped to manage transactions, but for entity beans it's mandatory that the container manages the transactional behavior - bean-managed transactions are only an option for session or message-driven beans (MDBs), but I'm getting ahead of myself.

What Are the Options?
In general in the EJB world, transactions can be container or bean managed. As you would expect, for container-managed transactions (CMTs), all the code to control the starting, committing, and aborting of transactions is provided and managed by the EJB container. For bean-managed transactions (BMTs), the bean implementer gets to use the JTA API set to control the transaction demarcation directly. As I mentioned, entity beans aren't permitted to use bean-managed transactions (presumably to encourage reuse of entity beans). In fact, the EJB specification states that any transaction in force when a BMT method is called should be suspended by the EJB container before the business logic is invoked. Thus, using BMT beans in various transactional contexts isn't possible.

Bean reuse is really maximized by using container-managed transactions. Additionally, when using message-driven beans, unless you use container-managed transactions, there can be no transactional integrity between the dequeuing of the JMS message the bean is about to process and any updates that the bean's onMessage method may cause to happen. You get the general picture.... Aside from those comments, I'll mention BMTs no further, since this article is about getting the application server to do the transactional work for you.

In the Beginning There Was the Transaction - Container Managed...
There are six different policies that can be associated with methods on a CMT bean: NotSupported, Required, Supports, RequiresNew, Mandatory, and Never. Code executed in methods marked NotSupported and Never will not execute in the context of an active transaction. If such a method is called in the context of a transaction, the transaction will be suspended in the NotSupported case and a RemoteException will be thrown to the caller in the Never case. Either way, any work done by the method will not cause more work to be added to a transaction.

Required and Mandatory methods, on the other hand, work in the context of an existing transaction. For the Required case, the container will start a new transaction before calling the method if no transaction is associated with the calling context. For the Mandatory case, if the method is called outside the context of a transaction, a TransactionRequiredException will be thrown. Methods marked RequiresNew will have a fresh transaction started for them by the container. Any caller's transaction will be suspended first. In either event, the method will always execute in the context of a transaction. Finally, the Supports policy allows the code to participate in any existing transaction context or in none, if it's called outside of a transaction scope.

As a general rule of thumb, I would consider it good practice to avoid the use of policies that leave you uncertain as to a method's transactional context. In particular, avoid Supports. In the same way that unintialized variables can cause hard-to-find bugs in systems (especially when code is reused) it's much better to state, "This must be used in a transaction" or "This can't be" rather than "Well, I'm not really sure."

So What Happened in the End?
So, it's all very well. You've told the container when to start transactions for you, but it can't see your business logic.... How does it know when a transaction should end, and whether it should end with a commit or an abort? In the general case, if the container started a transaction, "T," before invoking a method, "M," then it will commit "T" before returning the results of the Method to the requestor.

There are two exceptions to this behavior. The first occurs when the method throws a system exception. The second, an application exception, "should be used to communicate application-level problems to the client, such as "You can't withdraw that much money, it would put you in overdraft."

There's no reason for the container to assume you want to roll back a transaction because of an application exception. It's a common misconception that throwing any exception from a method will cause the current transaction to be rolled back. It won't. A System exception is an exception not covered by the application exception category. These typically indicate catastrophic technical failures - "I couldn't get a database connection", for example. If one of these is thrown, the transaction will be rolled back (or marked for rollback, if the container didn't start it). Technically, the container considers any exception that is a subclass of RuntimeException or RemoteException to be a system exception.

So, what if you want the current transaction to roll back, but you want to throw an application exception? Well, there's a method on the EJBContext interface called setRollbackOnly(). This method will mark a transaction rollback only, and if the transaction was started by the container, then calling this method from your business logic indicates that the transaction should be rolled back rather than committed when the method returns.

While we're on the subject, there's another EJBContext method that pertains to transactions: getRollbackOnly(). Clearly, if your bean has been called in the context of a transaction that's already doomed, then there's no point wasting lots of CPU cycles doing some complex calculation with results that will only be rolled back and thrown away. If your beans contain such CPU-intensive code, then you can introduce a good optimization only by checking if the transaction is marked rollback before you execute it.

Got the Message?!
So that's transactions and beans. Now, one final word about message-driven beans. For CMT message-driven beans, the dequeuing of the JMS message that gets passed to your bean's onMessage method is done in the same transaction context that your method is invoked in. If your code causes the transaction to be rolled back, by any of the means discussed above, then (thanks to the transaction manager and its good old ACID properties), it will be as if the message never got dequeued.

Of course, if the message hasn't been dequeued then it's still on the queue waiting to be consumed so the very next thing that will happen is that it will be dequeued and redelivered to your waiting onMessage method, which will throw an exception, the transaction will be rolled back... ad infinitum.

So be careful if you're writing MDBs - better to write errant messages to some dead-letter queue for your application and commit the transaction than throw an exception and abort it. Unless, that is, you get some kind of warped pleasure from watching app servers spinning around infinite loops. WebLogic's JMS implementation also provides some configurable parameters to handle this case, to delay redelivery of a rolled-back message, or to automatically place it on a dead-letter queue after some number of retries.

That's all for now. The nice men in white coats are coming to commit me but remember - if you're using an app server it should be barking, not you.... See you next 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 challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...