In my previous post, we’ve discussed about TransactionAttributeType.REQUIRES_NEW: how it behaves and where is a good spot to use it. In this post, which is the 2nd part of the series, we’ll explore TransactionAttributeType.MANDATORY.

TransactionAttributeType.MANDATORY is pretty straight forward where by if your method in a session bean is annotated with this, it has to be run within an already present/existing transaction. Why? because it can’t start its own transaction. In simple words, it runs when is was called FROM methods with REQUIRED, REQUIRES_NEW and SUPPORTS (if only the method with SUPPORTS was called by other methods which is running in a transaction).

In most cases, methods that are annotated with TransactionAttributeType.MANDATORY are more oftenly invoked by other methods that are running in the session bean rather than being invoked directly by JSP or Remote Clients.

Understanding TransactionAttributeType.MANDATORY

For the below example, I’ll illustrate the basic behavior of TransactionAttributeType.MANDATORY with 2 session beans by the name of ExampleSessionFacade1 and ExampleSessionFacade2 with their local interfaces as IExampleSessionFacade1Local and IExampleSessionFacade2Local for simplicity.

Looking at the codes above, we have methodA() in ExampleSessionFacade1, it is annotated with TransactionAttributeType.REQUIRED. Within methodA(), it invokes methodB() through the session bean instance of ExampleSessionFacade2. methodB() is annotated as TransactionAttributeType.MANDATORY. Now, how the container works is this: the container will start a transaction for methodA(), let’s call it T1. As ExampleSessionFacade1′s methodA() invokes methodB() of ExampleSessionFacade2 and since methodB() was annotated with MANDATORY, methodB() will run its operation within the same transaction as methodA(), which is T1. Both methods share the same transaction together.

So, if methodA() finishes flawlessly and commits, operations of both methodA() and methodB() will be commited back to the database. Likewise, if an exception occurs and context.setRollBackOnly() is triggered, both methods will be rollbacked simultaneously and nothing will be commited.

Scenario for TransactionAttributeType.MANDATORY to be In Action

In my opinion, if your process is too lengthy to be contained in one method and if you need to split the codes into two or more sub-process methods, having the other sub-process methods to be annotated with MANDATORY is a good choice. And at the same time, if a method is annotated as MANDATORY, may not be suitable for direct invocation from external clients like web front-end (JSP, JSF, etc.) or remote clients.


** You can only bring out the effects of transaction attributes only when you call the method through a session bean instance and NOT through a direct method call. Even if your methods are within the same bean, you need to get the local instance of the same bean and call through its local interface instead of a direct method invoke.

This message will appear in all the posts within this series as a REMINDER.

Need An Applied Example?

Remember the bank funds transfer process workflow that we did in the previous post on TransactionAttributeType.REQUIRES_NEW? Instead of coming out with something new, I’ll just refactor the previous applied example. Before you read on, I highly urge that you take a look at my previous post: Making sense of EJB3.x Transaction Attributes – Part 1 (REQUIRES_NEW) before we continue. I’m taking the same database table structure and all of the codes will pretty much be the same except for certain portion of it that refactoring is required.

Stateless Session Bean Refactoring

As I have stated above, in my opinion, I believe the best place to have a method in a session bean to be annotated as @TransactionAttribute( TransactionAttributeType.MANDATORY ) is if a business is too lengthy and it needs to be broken down into different sub-processes and these sub-processes should be within the same transaction as the caller and it should have very less chance that a direct invokation from external client could occur.

In the previous bank fund transaction workflow example, after the funds had been transfered and before the process commits, the bank charges will be added into the bank group accounts as a profit. Here, I’ll take the section of updating the bank group profit and make it into a separate business method as a sub-process of the whole fund transfer; and at the same time, I would assume that this method will have absolutely minimal chance of direct external client invokation (come on, the bank only makes a profit by charging for a transaction fee right?). I’ll refactor the method transferFunds in BankTransactionSessionFacade and I’ll name this separate process as addToBankProfit and put it within a stateless session bean name BankGroupSessionFacade with implemented interface as IBankGroupSessionFacadeLocal. I’ll annotate addToBankProfit as @TransactionAttribute( TransactionAttributeType.MANDATORY ).
So now, the transfer transferFunds method in BankTransactionSessionFacade shoud look like this:

follow by the the new session bean BankGroupSessionFacade with the addToBankProfit method:

The codes for IBankGroupSessionFacadeLocal:


Methods with TransactionAttributeType.MANDATOR could be run within methods that have transaction attributes such as REQUIRED, REQUIRES_NEW, MANDATORY and Supported (if only it is run within an already started transaction). In the contrary, it should not be invoked by methods with NOT_SUPPORTED and NEVER as it will not consist of a running transaction with MANDATORY to ride on.

In my next article, I’ll touch on both SUPPORTS AND NOT_SUPPORTED at the same time as they are quite related in certain context. Meanwhile, I do hope very much that this article could clear the fog of understanding the MANDATORY transaction attribute.

Thank you for reading.

Related Articles

Max Lam
About the Author

Born and currently resides in Malaysia, a seasoned Java developer whom had held positions as Senior Developer, Consultant and Technical Architect in various enterprise software development companies.

Related Posts

(adsbygoogle = window.adsbygoogle || []).push({}); This is a quick guide on how to install a...

This is the last part in the series of “Making sense of EJB3.x Transaction Attributes“. So far,...

Oracle had extensively documented the behavior of each transaction attributes in the Java EE...