This is the last part in the series of “Making sense of EJB3.x Transaction Attributes“. So far, we’ve discussed transaction attribute type REQUIRES_NEW, MANDATORY, SUPPORTSand NOT_SUPPORTED. Here, we’ll cover the last attribute which is “NEVER“. The NEVER transaction attribute type is a simple one, but yet sometimes, it is difficult and confusing to where it can be applied in your Java EE project. This is a very short article with no code samples except to tell you where I think the NEVER transaction attribute type should be used.

In fact, TransactionAttributeType.NEVER tells a method in a session bean not to get involve with any transaction. Yes is as simple as that. Truthfully, TransactionAttributeType.NEVER is very rigid and it is so strict that even when it detects that there is a living transaction that the method annotated is involved, it throws an EJBException. But there are good uses for it.



STICKY IMPORTANT HIGHLIGHT!!!

** 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.

When to use TransactionAttributeType.NEVER

In my opinion, a method should be annotated with TransactionAttributeType.NEVER if it only consist of logics that “NEVER” touches the database or any invocation of other methods which are transactional. Thus, the word NEVER.

For my past projects, I’ll annotate session bean methods with NEVER if they are only specifically involve in physical file reading and writing (I’ll skip the debates on EJB specs), raw number crunching, cropping/transformation/editing of an image, algorithms which serves an algorithmic purpose (funny, but it makes sense e.g. calculation of the upper and lower Bollinger bands for financial numbers) or even password encryption and decryption. These are just some of the examples of usage for methods with NEVER transaction attribute type. Notice that the above use cases didn’t touch any database layer and whatever the method processes, it is final and no correction when things go wrong. If you have specific use cases like this, NEVER is just the answer to your session bean method.

The benefits of using TransactionAttributeType.NEVER is it doesn’t involve any database transaction and thus it has limited overhead in usage of app server resources.

Transaction Attribute Types That “NEVER” Co-exists:

A session bean method that is annotated as NEVER is safe to be invoked by another session bean method that is annotated by TransactionAttributeType.NOT_SUPPORTED, as it will suspend any transaction before carrying out its business.

Summary

I hope that you have gain much by reading all of this 4 part series of transaction attributes. Knowing the behavior of the attribute type will just increase your knowledge, but knowing when to use them at the right time in the right places will do wonders in your application.

Hope you’ve enjoy 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...

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

In my previous post, we’ve discussed about TransactionAttributeType.REQUIRES_NEW: how it behaves...