One Stateless Session EJB for Utility functions?

Question

I have some utility functions which may be called from multiple Stateless Session EJBs. These utility functions needs to be in a new transaction (RequiresNew).

Does it make sense to create one Stateless Session EJB for all these functions may be call it Utility?

Or should I try to have them organized by functionality in which case I will end up with multiple Stateless Session EJBs? What will be the impact on performance of system if I have lot of such Stateless Session EJBs?

Some examples of utility functions:

I have a table where I store messages with Id. Create a utility function to retrieve a message for a specific Id. Create a utility function to update a message for a specific Id.
I have a table where I keep track of statuses of some processes. Create a utility function to give status of a specific Process. Create a utility function to update status of a specific Process.

etc.

If they require a new transaction (and thus state), they definitely aren't "utility functions". — BalusC, Jan 15 '16 at 14:07
As per your edit: Those are just MessageService and ProcessService EJBs? Or aren't you aware that you can safely inject another EJB in one EJB? Utility functions are static methods in a class without any instance variables. — BalusC, Jan 15 '16 at 14:10
@BalusC New Transaction is needed for these functions because they may be called from another transaction and want these functions to commit regardless of the calling transaction's commit or rollback — ChumboChappati, Jan 15 '16 at 14:22
That's perfectly doable, but those definitely aren't "utility functions". — BalusC, Jan 15 '16 at 14:26
@BalusC Thanks. So separate EJBs with injection is the answer. Do you want to answer it so I can accept it? — ChumboChappati, Jan 15 '16 at 14:30

score 1 · Accepted Answer · answered Jan 15 '16 at 21:49

From a performance point of view, for every stateless EJB, the container must instantiate and manage a bean pool containing instances of that bean. (This typically isn't large, since stateless beans can be used interchangeably. I believe the default in JBoss AS is 20 instances/pool) If you combine these into a single bean, only one pool is required, but it will probably need more instances, since they must serve all the types of call. So performance isn't going to be affected noticeably.

I much bigger problem is encapsulation - having a "utility" session bean would entirely violate separation of concerns, it would leave you with one class with many different purposes and dependencies. It risks becoming a Ball of Mud, will mix dependencies for all the methods, and it will make your code harder to maintain, since it is harder to work out where these functions are.

I'd highly recommend thinking more about whether there are meaningful functional units to separate these methods into, even if they are each quite small. As other commenters have suggested, your two examples sound like good candidates for a ProcessService and a MessageService. You may find that when you look at the sets of functionality you want to add that these aren't the best way to divide things up, but it's probably a good starting point. If you put in the effort now to identify what the distinct logical services are in your system, you'll reap the rewards in extensibility and maintainability later.

One Stateless Session EJB for Utility functions?

1 Answers1