Java Reference
In-Depth Information
Centralized clearinghouse
Although centralized chokepoints are the anathema to writing scalable software, there are
times when this is necessary. Perhaps the bean is interacting with a legacy system that's
limited in its connectivity. More likely you'll have situations where you want to cache a
value once and control its value while making it available to multiple clients. With the con-
currency control, you can enable concurrent reads while enforcing synchronization on the
writes. So, for instance, you may want to cache a value in memory so that each web visit
results in a database hit.
Counterpoint
Singleton session beans should be used to solve problems that call for a singleton and re-
quire services of the container. For example, a singleton bean shouldn't be used to imple-
ment logic that verifies a phone number. That doesn't need to be a singleton nor does it re-
quire any services from a container. It's a utility method. If the bean isn't caching or guard-
ing state from concurrent access or modification, then it shouldn't be a singleton session
bean. Because singleton beans can be a bottleneck if used incorrectly, a large application
should be weighted primarily toward stateless session beans, some stateful session beans,
and a handful of singleton beans if necessary.
You should never use singletons as stateless services; rather, use stateless session beans
instead. Most stateless services aren't read-only and require database interaction through
non-thread-safe APIs like the JPA entity manager. Using a thread-safe singleton in such a
case doesn't scale because there's only one instance of a bean that must be shared by all
concurrent clients. Now that you have a basic grasp of singleton session beans, let's dive
into a code example.
3.4.2. ActionBazaar featured item example
Each day ActionBazaar Company spotlights a particular item or featured deal, as shown in
figure 3.11
.
Shortly after midnight the site is refreshed to reflect the new deal. A couple
of years ago the logic for the hot deal could have resided in the web tier, because there
was only one interface to the application. But ActionBazaar now sports native iPhone and
Android apps that use a restful web service along with a dedicated mobile website. This
logic is thus pushed down into the business layer. Because this information is essentially
static, it doesn't make any sense to load it each time someone visits the website. Hitting
