Originally posted by Renaud FLORQUIN:
I'm not an EJB specialist but for me a bean should not call a class with synchronized code (raison: the concurrency is controlled by the container). A stateful bean can build a cache but only for its own client (concurrent call is not allowed for a Stateful Session Bean).
Renaud
I'm sure that a DBMS implemented in
Java uses synchronization, yet is called by an EJB. But perhaps it's a bad example, in that a DBMS runs in a different process, and must observe certain resource-provider J2EE contracts that ordinary developers don't worry about.
What does disturb me is that there is so much repetition of code in the two service locators. That's an Extreme Programming no-no. I suspect that one could implemented such that users of a "getSingletonServiceLocator" routine would use caching, but those using a simple "new ServiceLocator" would not. But the code would then be more confusing; even if you were only interested in one tier, you would still have to understand the needs of the other tier to appreciate the ServiceLocator code. Furthermore, you'd have to package it differently so it could be deployed to both tiers.
Can anyone think of an elegant way to eliminate the code redundancy? Maybe some kind of decorator to the ServiceLocator that adds caching! But the code for the decorator might be just a big as a second ServiceLocator (and harder to read).
Part of me says that whenever there is redundancy in a program and no good way to remove it, that's a sign that a new language construct is needed!
