Scopes, lifecycle and thread-safe singleton design
Prerequisites: 01-ecosystem
When is a bean ready for advised calls?
Goal & mental model verified
A singleton is one instance per bean definition per container. Request scope follows a web request. The container manages initialization/destruction for managed beans, with important exceptions such as prototype destruction.
[S17] [S18]Worked example · design exercise synthesis
QuoteService may safely be a singleton when it stores only stable collaborators. A mutable currentTenant field would mix simultaneous requests; carry tenant context through an explicit request-level mechanism instead.
[S17] [S18]Engineering decision synthesis
Keep shared service state immutable or deliberately synchronized. Choose scope by ownership and lifetime; request-scoped dependencies in singletons need appropriate proxies or lookup.
[S17] [S18]Pitfall & diagnosis synthesis
@PostConstruct runs during initialization, before normal proxy-mediated use. Depending on transactional advice there is unsafe. Prototype cleanup is not automatically managed like singleton destruction.
[S17] [S18]Improve & validate synthesis
Move external startup work into a suitable lifecycle stage. Test concurrent requests and shutdown; name who owns cleanup for prototype or manually created objects.
[S17] [S18]Check yourself: Does singleton mean one instance across a cluster?
No. Each application container has its own singleton instances.