@Singleton vs @ApplicationScope

Question

For a project I need to have a unique ID generator. So I thought about a Singleton with synchronized methods.

Since a Singleton following the traditional Singleton pattern (private static instance) is shared accross Sessions, I'm wondering if the @Singleton Annotation is working the same way?

The documentation says: Identifies a type that the injector only instantiates once.

Does it mean, that a @Singleton will be independent per User Session (which is bad for an id-generator)? Should I prefer an old school Singleton with Class.getInstance() over an Injection of an @Singleton-Bean?

Or should I use neither nor and provide the Service within an @ApplicationScoped bean?

it musst be guaranteed that only ONE thread, independent of the user session can access the method to generate the next id. (It's not solvable with auto-increment database ids)

Edit: JSF 2.2, CDI and javax.inject.* i'm talking about :)

Mooneyham

Answer 1

All those kinds of singletons (static, @javax.inject.Singleton, @javax.ejb.Singleton and @javax.enterprise.context.ApplicationScoped) are created once per JVM.

An object that is created once per user session must be annotated with @javax.enterprise.context.SessionScoped so no, singletons will not be instantiated per user session.

Notice that there are two @Singleton annotations, one in javax.inject and the other in the javax.ejb package. I'm referring to them by their fully-qualified names to avoid confusion.

The differences between all those singletons are subtle and I'm not sure I know all the implications, but a few come to mind:

• @javax.ejb.Singleton is managed by the EJB container and so it can handle transactions (@javax.ejb.TransactionAttribute), read/write locking and time-outs (@javax.ejb.Lock, @javax.ejb.AccessTimeout), application startup (@javax.ejb.Startup, @javax.ejb.DependsOn) and so on.
• @javax.enterprise.context.ApplicationScoped is managed by the CDI container, so you won't have the transaction and locking features that EJB has (unless you use a post-1.0 CDI that has added transactions), but you still have lots of nice things such as @javax.enterprise.inject.Produces, @javax.annotation.PostConstruct, @javax.inject.Named, @javax.enterprise.inject.Disposes (but many of these features are available to EJBs too).
• @javax.inject.Singleton is similar to @ApplicationScoped, except that there is no proxy object (clients will have a reference to the object directly). There will be less indirection to reach the real object, but this might cause some issues related to serialization (see this: http://docs.jboss.org/weld/reference/latest-2.2/en-US/html_single/#_the_singleton_pseudo_scope)
• A plain static field is simple and just works, but it's controlled by the class loader so in order to understand how/when they are instantiated and garbage collected (if ever), you will need to understand how class loaders work and how your application server manages its class loaders (when restarting, redeploying, etc.). See this question for more details.

Breskin

One Small correction: All those kinds of singletons (static, @javax.inject.Singleton, @javax.ejb.Singleton and @javax.enterprise.context.ApplicationScoped) are created once per JVM. You can technically have multiple applications running in a single JVM, and the spec allows for it. These items are generally scoped to the application, making ApplicationScoped the best named – Inquietude

Also a good point to mention about @javax.inject.Singleton is to use it when that bean uses things like JDBC directly or network tcp/connection objects since those cannot be serialized? – Harless

Answer 2

javax.inject.Singleton - When used on your bean, you have to implement writeResolve() and readReplace to avoid any serialization issues. Use it judiciously based on what your bean actually has in it.

javax.enterprise.context.ApplicationScoped - Allows the container to proxy the bean and take care of serialization process automatically. This is recommended to avoid unprecedented issues.

For More information refer this page number 45.

Sacculus