Are the objects in the "single set accessed by all clients" ever persisted? If so, the DB itself should be your single set accessed by all clients. Then you can allow any number of EJB instances from a pool to access the same DB table(s) at the same time. For reading, you don't care how many readers there are. If multiple writers are creating new objects, that's ok - different ids will be assigned to each by your id generation strategy. If multiple writers are attempting to update the same object at the same time, you need to use optimistic locking (by a timestamp or version attribute) or pessimistic locking (rarely used) to prevent losing changes.
Forcing all activity to go through a single EJB is not scalable performance-wise and may also may cause memory issues if the set grows too large.