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

Related Topics: Weblogic

Weblogic: Article

Tricky Transactions

Understanding implicit transactions in WebLogic Integration

BEA WebLogic Workshop is fabulous at hiding many of the complexities of a J2EE application. This can be a problem when things don't behave this way you might expect. Tools are great, but sometimes do things "for us" that we really don't want.

Understanding what the tool is doing is key to knowing when a problem might arise. In this article I'll cover the details of how WebLogic Integration handles transactions, referred to as implicit transactions, within a BPM process. Truth be told, you really shouldn't need to know or care about these transactions. There are, however, some cases where they become important. Knowing how they work and where they exist is key to understanding the implications of process design.

The first and most obvious implication is performance. Transactions are inherently expensive. If you have unnecessary implicit transactions, it may be possible to modify the process to reduce these and improve performance. However, the biggest performance impact is transitioning from one implicit transaction to two. This is due to how WebLogic implements a given process. If a process has only one implicit transaction, then WebLogic Workshop can deploy this process as a stateless session bean. If it has more than one, it must use an entity bean. As you might guess, an entity bean adds overhead to the process and reduces performance.

I won't go into detail about the architectural patterns associated with processes with a single transaction versus a process with multiple transactions. Suffice it to say that a single transaction process is usually a worker or utility process. It will take something in, do the work, and send it somewhere else. Obviously we want these processes to be fast, and we want to make sure we do not accidentally introduce an extra implicit transaction. Processes with multiple transactions are usually long running where performance is not a huge concern.

The second implication of implicit transactions is behavior. Transaction boundaries are set for you, so it may not be obvious that a failure in one node of the process may actually cause the rollback of another node.

Consider the process segment shown in Figure 1. A developer may add a logging node above a JMS send node to try to figure out why the JMS is failing. Perhaps they are confused and believe that if the JMS fails, it will also roll back the entry in the database because they are in a single transaction.

Be aware that it is always possible to place an explicit transaction into the process. These are not confusing because the developer manually inserts them and they are clearly visible when the process is displayed.

So how do we know where the implicit transaction boundaries are located? The basic rule of thumb is: if the process stops and waits, then it must start a new transaction. There are a couple of exceptions to this that I will address later. This sounds easy but can get tricky. Here's a quick education.

I will use perform nodes as placeholders for discussion.

Consider the process segment shown in Figure 2. It is a very simple process that has a start node, perform, and end. It is easy to identify that this has a single implicit transaction, and that this process will be deployed as a session bean.

Consider the process segment shown in Figure 3. It adds a control receive into the process. As I said before, whenever the process has to wait, it adds a new implicit transaction. There will be two transactions then: one from the start node to the top of the Control Receive (Tx 1) and one from the Control Receive to the end (Tx 2).

Note: A synchronous Control Send with Return does not add an implicit transaction.

Consider the process segment shown in Figure 4. It includes a parallel path. Whenever one is reached, a new transaction is started for each branch. Once the parallel paths come back together, another transaction is started. In this instance, there are four transactions. There are two points to be noted. If the parallel join node is an OR rather than an AND, one of the transactions (Tx 2 or Tx 3) will not execute. I'll cover this in more detail later. In the initial release of BEA WebLogic Integration 8.1 there was a problem with the final transaction. A new transaction was not started after the parallel join. Nodes after the join would be in the same transaction as the final parallel path executed. This has been fixed in Service Pack 2.

Consider the process segment shown in Figure 5. It includes an event choice. Much like a single Client or Control Receive, a new implicit transaction is started. Then, whichever event comes in first will be in the same transactions as the nodes below the event choice. Unlike the parallel node, there is no new transaction created when the paths visually come back together.

Consider the process segment shown in Figure 6. It is the most confusing case of transactions. The process never really stops, but a second transaction is started after the Client Response. For brevity's sake, I will not go into details here. Suffice it to say that in order to implement this process, it must save its state, return data back to the client (synchronous), and then restart the process at the node following the return.

That's it! It appears easy but can be tricky. Now I'll go through a series of tests. For each figure, write down (or draw) where you think the transaction boundaries exist. The answers are provided to show you how well you did. The average for an "expert" is 80%.

Note: These processes are for explaining implicit transactions only. They do not demonstrate best practices for building processes.

See if you can determine how many transactions each example contains.

Good luck!

Question #1 (Figure 7)
This is a simple synchronous client request with return.

Question #2 (Figure 8)
This adds a perform node after the client return.

Question #3 (Figure 9)
This has a branch with three paths. Assume there are no transactions before Node A or after node E.

Question #4 (Figure 10)
This is the same as Figure 9 except the join at the end of the parallel paths is an OR rather than an AND.

Question #5 (Figure 11)
This has two branches, but each branch has a client request node added.

Question #6 (Figure 12)
This has the client request node removed from the second branch path. Be careful, this one is tricky.

Question #7 (Figure 13)
This has a three-branch Decision node.

Question #8 (Figure 14)
This has a While Do loop.

Question #9 (Figure 15)
This has an Event Choice.

Question #10 (Figure 16)
This has a loop around a Client Receive. Assume the While Do returns back to the top twice (Node B and Node C Path executes three times).

Final Exam (Figure 17)
This one has a little bit of everything. If you answer this correctly, you are on your way to understanding implicit transactions!

How did you do? It's not as easy as it looks.

Be sure to watch out for transactional boundaries when you are building your processes. If the behavior is not what you want, then put in an explicit transaction. If you have a utility process that is simply doing work, be sure not to introduce too many transactions. BEA WebLogic Workshop and BEA WebLogic Integration are powerful tools. Use them wisely and take advantage of their strengths.

Answer #1 (Figure 7)
There is one transaction. If a node were placed after the return (before the finish), then a second transaction would be created.

Answer #2 (Figure 8)
There are two transactions. Node A is in Tx 1, Node B is in Tx 2.

Answer #3 (Figure 9)
There are five transactions. Each of the perform nodes is in its own transaction. Note: This is only true because it is an AND join at the end. If this was an OR, then only one of the branches would be executed.

Answer #4 (Figure 10)
There are three transactions. Node A is in Tx 1, Node B (or C or D) is in Tx 2, and Node E is in Tx 3. Since the parallel node is an OR, it will not go down the other two paths, therefore, Node C and Node D will not run. Note: It is indeterminate as to which branch of a parallel branch is executed first. The sequence may change between executions.

Answer #5 (Figure 11)
There are five transactions. Node A is in Tx 1. Node B is in Tx 2. Node D is in Tx 3. Assuming client request 1 comes in before client request 2, Node C is in Tx 4; the parallel branch ends because it is an OR and Node F is in Tx 5.

Answer #6 (Figure 12)
There could be three or four transactions. Assume the left path is executed first. Node A is in Tx 1. Node B is in Tx 2. Nodes D and E are in Tx 3. Node F is in Tx 4. What happens if the right path is executed first? Node A is in Tx 1, Node D and E are in Tx 2 and Node F is in Tx 3. Node B is not executed in this case.

Answer #7 (Figure 13)
There is one transaction. I never mentioned decision nodes in the previous discussion. Based on the decision, Node A; Node E; and one of B, C, or D will all be in the same transaction.

Answer #8 (Figure 14 )
There is one transaction. Looping constructs have no effect on transactions.

Answer #9 (Figure 15)
There are two transactions. Node A is in Tx 1. Assume the Client Receive is first. Nodes B and D are in Tx 2. If the Control Receive is first, then Nodes C and D are in Tx 2.

Answer #10 (Figure 16)
There are four transactions. Nodes A and B are in Tx 1. Nodes C and B are in Tx 2. Nodes C and B are in Tx 3. Nodes C and D are in Tx 4. It is important to mention that nodes at the bottom of the loop are in the same transaction as those in the top of the loop in the next iteration. In this case, a rollback may be confusing.

Answer Final Exam (Figure 17)
There are six transactions. Node A is in Tx 1. Assume the left branch is first. It doesn’t matter. Node B is in Tx 2. Node C is in Tx 3. Assume the far left Client Receive is first. Node D is in Tx 4. It waits because the join node on the Parallel path is an AND (+). Assume either Client Request or onMessage is received next. Node E is in Tx 5. Node F is in Tx 6.

More Stories By John Graves

John Graves has been with BEA for more than seven years and is currently working as an internal trainer for Education Services specializing in WebLogic Portal. He spent the first five years of his time with BEA in the Advanced Service Group doing full life-cycle project work.

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
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
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...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...