@Singleton vs @ApplicationScope
For a project I need a unique identifier generator. So I thought about Singleton with synchronized methods.
Since the Singleton, following the traditional Singleton ( private static instance
) pattern , is split across sessions, I'm wondering if @Singleton
Annotation works the same way?
The documentation says: Identifies a type that the injector only instantiates once.
Does this mean that a @Singleton
will be independent on User Session
(which is bad for an id generator)? Should I use old school
Singleton with Class.getInstance()
Over Injection @Singleton
- Bean?
Or should I neither use the service nor provide the service in the @ApplicationScoped
bean?
you need to ensure that only one thread, regardless of the user's session, can access the method to create the next identifier. (It is not allowed with auto-increment database IDs)
Edit: JSF 2.2, CDI, and javax.inject.*
I'm talking about :)
source to share
All these types of singletons ( static
, @javax.inject.Singleton
, @javax.ejb.Singleton
and @javax.enterprise.context.ApplicationScoped
) are generated once for each the JVM .
An object that is created once per user session must be annotated @javax.enterprise.context.SessionScoped
so no, no instances will be created for a user session.
Note that there are two annotations @Singleton
, one in javax.inject
and the other in the package javax.ebj
. I mean by their fully qualified names to avoid confusion.
The differences between all of these loners are subtle, and I'm not sure I know all the implications, but some come to mind:
-
@javax.ejb.Singleton
is managed by an EJB container, so it can handle transactions (@javax.ejb.TransactionAttribute
), read / write locks and timeouts (@javax.ejb.Lock
,@javax.ejb.AccessTimeout
), application startup (@javax.ejb.Startup
,@javax.ejb.DependsOn
), and so on. -
@javax.enterprise.context.ApplicationScoped
controlled CDI container, so you will not have a transaction, and lock functions that are in the EJB (if you do not use the CDI after 1.0, which added to the transaction), but you still have a lot of good things, such as@javax.enterprise.inject.Produces
,@javax.annotation.PostConstruct
,@javax.inject.Named
,@javax.enterprise.inject.Disposes
(many of these functions are also available for EJBs). -
@javax.inject.Singleton
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 the real object, but it might cause some serialization-related problems (see this: http://docs.jboss.org/weld/reference/latest-2.2/en-US/html_single/#_the_singleton_pseudo_scope ) - A simple static field is simple and works, but it is controlled by a classloader, so to understand how / when they are created and collected by the garbage collector (if ever), you need to understand how classloaders work and how the application server manages its class. ... loaders. See this question for more details.
source to share
javax.inject.Singleton - When using your component, you must implement writeResolve()
and readReplace
to avoid serialization issues. Use it wisely based on what's actually in it.
javax.enterprise.context.ApplicationScoped - Allows the container to proxy the component and automatically perform the serialization process. This is recommended to avoid unprecedented problems.
For more information refer to this page number 45.
source to share