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