Can anyone shade some light on the difference between ApplicationScope(JSF) and Singleton(Spring MVC). I have a application written in jsf in which one of the class uses application scope. And while converting to spring I used Singleton scope which I believe slightly equivalent to Application scope. But want to dig in deep to know what actually varies between both in areas such as performance etc.
Both are similar in the sense that, once started they will live on until the application ends (or the class is garbage collected, which you not happen in a typical Java EE application until you undeploy).
Both are shared instances and you should make sure that they are thread safe.
From Java EE 7 Tutorial
#ApplicationScoped Shared state across all users' interactions with a web application.
From Spring Documentation:
Spring's concept of a singleton bean differs from the Singleton pattern as defined in the Gang of Four (GoF) patterns book. The GoF Singleton hard-codes the scope of an object such that one and only one instance of a particular class is created per ClassLoader. The scope of the Spring singleton is best described as per container and per bean. This means that if you define one bean for a particular class in a single Spring container, then the Spring container creates one and only one instance of the class defined by that bean definition.
So unless you are, for example, using a back end singleton bean to serve multiple web applications (say in a EAR project with multiple web projects - in this case, the Singleton Bean may outlive the Application bean if you stop / undeploy the web-application but not the EAR) or destroy your Spring application context with your web application still running (in this case your Application Bean may outlive your Singleton Bean) both life cycles are very similar.
Anyway, I think that mixing Spring, JSF and DI xml / annotations is not a good idea. This article goes in detail about how to integrate the three (also, how to make it in a way that you can work with only one of the technology for the annotations).
So, #Named #ApplicationScoped + make sure that you get concurrency right = profit! :)
Related
I need to declare a Spring bean using Annotation-based config, which will be available throughout the runtime of the Application Server (in my case, JBoss). I should be able to write and read the data to/from the bean across multiple requests. I have read about the global session scoped bean, but couldn't find any concrete examples. Is there a way to implement this and what are the thread-safety concerns with this kind of bean?
Best Regards,
Chandra.
I have been reading lately about safe publication of Java objects (e.g. here: http://shipilev.net/blog/2014/safe-public-construction/).
Until now I was trusting EJB container without questions when relying on container managed concurrency.
Now I'm wondering
1) how an EJB container can make sure that the EJB itself is published safely?
2) how an EJB container can make sure that objects created by its EJBs are published safely (e.g. EJB instance vars)?
E.g. stateless session bean can be accessed by different threads over time (I'm not necesseraly saying simultaneously), so unsafe publication is a potential issue.
For 1), I roughly see possibilities, e.g. by wrapping the EJB and using some volatile accesses to garantuee total order.
For 2), I don't see how EJB container can enforce it.
Maybe it is forbidden by the EJB 3.1 spec to keep instance variables in the EJB if it can be accessed by different threads?
Maybe the statement "don't worry about concurrency in container managed EJB" is not true, and I should use safe publication patterns (including volatile and/or final keywords) in the class definitions of the classes used in my EJB instance vars?
I'm surpirsed I missed this fundamental problemacy for that many years as a Java developer.
Regards,
Lars
If an EJB container is reusing instances, it must store them in a thread-safe object pool, which must use some synchronization (synchronized, compare-and-swap, etc.), which will ensure that everything written by the first thread will "happen-before" everything that happens on the second thread. EJB developers do not need to worry about synchronization (unless they're using singleton session beans with bean-managed concurrency or the EJB is going outside the scope of the EJB spec by storing data in static variables).
I have read different articles on using #Stateful and #SessionScoped annonations and their differences including this post. From a definition point, #sessionScoped is used when a session is needed/created between client/web tier, while #Stateful is needed in Bussiness Logic layer. But I still do not get a hold of the real differences when it comes to implementing them. Here is a simple example
#Named
#SessionScoped
ShoppingCartUIBean {
#inject
shoppingCart cart;
// more code
}
#Stateful
ShoppingCart {
//business logic of adding/updating/deleting cart items
}
How is the Http session maintained by #SessionScoped bean between a given user and server?
That is, if I have a shopping cart opened in different computers, I should be able to see my shopping cart, which is associated with my user profile. How is this established?
what happens if I switch the two annonations on the above beans? will it have any effect?
(sorry this might sound stupid. I am getting into Java EE world, so I want to get basics correct).
According to this great post on Differences : #SessionScoped vs #Stateful and #ApplicationScoped vs #Singleton, #Stateful beans are hardly used in web applications. Is there a case where #Stateful is absolutely necessary?
ON a related note: is it legal to inject a #stateful bean into #ApplicatonScoped bean? This would mean entire the application has a single #stateful bean and all clients uses the same instance of one stateful bean via proxy. (Just as is demonstrated here, not to inject #Stateful in servlets EJB example for stateless and stateful beans difference).
Thanks.
I will try to answer some of your question with my best.
Ad.1 #SessionScoped is about browser session, so you won't see the same session on different computers(or browsers).
Ad.2 You can't think about those two as the same components only because the same scope. Fundamental think is that EJB and JSF beans rely on different architecture layers. EJB beans should implement business logic while jsf beans should maintain forms and other ui components.
Ad.3 #Stateful beans are very useful in seam framework. Using those beans and extended persistance context is solution for lazy initialization error(probably that's a reason why seam creators use those beans). I prefer Stateless beans according to performance but it hardly depends on use case(whether you want keep state or not).
Ad.4 In general you shouldn't inject "less scope" beans to "more scope" beans. Application scope will exist while session may be destroyed and what this application bean should have in place of destroyed session bean?
Correct me if i'am wrong with any of this answers.
This question already has answers here:
How do servlets work? Instantiation, sessions, shared variables and multithreading
(8 answers)
Closed 6 years ago.
I need to know why the servlets are not thread safe ? And whats the reason that in Struts 2.0 framework controller servlet is thread safe ?
I need to know why the servlets are not thread safe ?
Servlet instances are inherently not thread safe because of the multi threaded nature of the Java programming language in general. The Java Virtual Machine supports executing the same code by multiple threads. This is a great performance benefit on machines which have multiple processors. This also allows the same code to be executed by multiple concurrent users without blocking each other.
Imagine a server with 4 processors wherein a normal servlet can handle 1000 requests per second. If that servlet were threadsafe, then the web application would act like as if it runs on a server with 1 processor wherein the servlet can handle only 250 requests per second (okay, it's not exactly like that, but you got the idea).
If you encounter threadsafety issues when using servlets, then it is your fault, not Java's nor Servlet's fault. You'd need to fix the servlet code as such that request or session scoped data is never assigned as an instance variable of the servlet. For an in-depth explanation, see also How do servlets work? Instantiation, sessions, shared variables and multithreading.
And whats the reason that in Struts 2.0 framework controller servlet is thread safe ?
It is not thread safe. You're confusing the Struts dispatcher servlet filter with Struts actions. The struts actions are re-created on every single request. So every single request has its own instance of the request scoped Struts action. The Struts dispatcher servlet filter does not store them as its own instance variable. Instead, it stores it as an attribute of the HttpServletRequest.
Servlets are normal java classes and thus are NOT Thread Safe.
But that said, Java classes are Thread safe if you do not have instance variables. Only instance variables need to synchronize. (Instance variable are variables declared in the class and not in within its methods.
Variables declared in the methods are thread safe as each thread creates it own Program Stack and function variables are allocated in the stack. This means that variable in a methods are created for each thread, hence does not have any thread sync issues associated.
Method variables are thread-safe, class variables are not.
There is a single instance of a servlet per servlet mapping; all instance properties are shared between all requests. Access to those properties must take that in to account.
Struts 2 actions (not "controller servlet", they're neither servlets nor controllers) are instantiated per-request. Action properties will be accessed only by a single request's thread.
Servlets are normally multi-threaded.
Servlet containers usually manage concurrent requests by creating a new Java thread for each request. The new thread is given an object reference to the requested servlet, which issues the response through the same thread. This is why it is important to design for concurrency when you write a servlet, because multiple requests may be handled by the same servlet instance.
The way that servlet containers handle servlet requests is implementation dependent; they may use a single servlet, they may use servlet pooling, it depends on the vendor's system architecture.
Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues.
Servlet is not thread safe but we can make it as a thread safe by implementing that servlet class to SingleThreadModel
like the given below class definition but again the performance problem will be there so better option would be use synchronized portion
public class SurveyServlet extends HttpServlet
implements SingleThreadModel
{
servlet code here..
...
}
Servlet is not thread-safe by itself. You can make it thread-safe by making the service method synchronized.
you need to implement SingleThreadInterface to make it thread-safe.
We all know that in the web tier there is the possibility that only a single instance of a given Servlet exists which services multiple requests. This can lead to threading issues in instance variables.
My question is, is it safe to inject an EJB using the #EJB annotation into a servlet as an instance variable?
My initial instinct would be no, under the assumption that the same instance of the EJB would service multiple requests at the same time. It would seem that this would also be the instinct of a number of other programmers: Don't inject to servlets
However have I jumped to the wrong conclusion. Clearly what is injected into the servlet is a proxy, under the hood does the container actually service each request with a different instance and maintain thread safety? As this forum would suggest: Do inject to servlets
There seems to be a lot of conflicting opinions. WHICH IS CORRECT???
It is safe to inject an EJB in a Servlet as a Servlet instance variable, as long as the EJB is Stateless. You MUST NEVER inject a Stateful Bean in a Servlet.
You must implement your EJB stateless in that it doesn't hold any instance variable which itself holds a stateful value (like Persistence Context). If you need to use the persistence context, then you must get an instance of it IN the methods of the EJB. You can do that by having a PersistenceContextFactory as a EJB instance Variable and then you get an instance of the entity manager from the Factory in the method of the EJB.
The PersistenceContextFactory is thread-safe, thus it can be injected in an instance variable.
As long as you comply to the above mentioned rules, it should be thread-safe to inject a Stateless Bean in a Servlet
Your reference "Don't inject to servlets" mentions nothing about ejbs or #ejb annotation. It talks about not thread safe objects such as PersistenceContext.
Per EJB spec you can access ejbs from variety of remote clients including servlets (EJB 3.0 Specification (JSR-220) - Section 3.1). Injecting ejb using #EJB annotation is a method of obtaining EJB interface via dependency injection (section 3.4.1) which is alternative to looking up ejb objects in the JNDI namespace. So there is nothing special about #EJB annotation with respect to EJBs obtained.
So, based on EJB 3.0 Spec, it's a standard practice to obtain ejbs from servlets using #EJB annotation.
It's a mixed bag.
Stateless session beans may be injected and are safe. This is because even if a single instance of a stub is used, access to the methods will be serialized by the container.
I think what inferreddesign says is not true. It doesn't matter if the stateless session bean uses a persistence context. Only one caller will ever access a single bean instance at the same time, so even though the persistence context is not thread safe, the EJB guards against multiple access to it. Think of it as if every session bean method has the synchronized keyword applied to it.
The main problem with injecting an EJB in a Servlet I think is performance. The single stub instance will become a major area of contention when multiple requests are queuing up while waiting for a session bean method to be executed for them.
I think the simple answer is that you aren't guaranteed that it is safe.
The reason for this is that there is nothing explicit in the EJB specification that says EJB home interfaces have to be thread safe. The spec outlines the behaviour of the server side part only. What you will probably find is that the client skeletons are actually thread safe but you would need to look at how they are implemented by the library you are using. The annotation part will just expand into a service locator so that doesn't buy you anything.