Can someone list the practical use cases of Request , Session and Global-Session scoped beans ? In most of the projects I have been using singleton and prototype . I understand that request scope beans are instantiated per request and in session scoped beans , the beans are instantiated when a session gets started .
Please enlighten me on the practical aspects .
So far we're using request scoped beans for information that should only be valid on one page like the result of a search or the confirmation of an order. The bean will be valid until the page is reloaded.
A session scoped bean is useful to hold authentication information getting invalidated when the session is closed (by timeout or logout). You can store other user information that you don't want to reload with every request here as well. Or another use case for us is to store a conversation scope in the session scope which we use to persist information between requests but to that we can assign a custom timeout and invalidation condition.
Pretty much any information that needs to be available after the request needs to be stored in the session scope. The only exception we use is with a view scope that stores information in the page's view map to be available after ajax requests for example in wizzards.
Singleton scope however means, that the information exists only once per application so if two users request your page they will access the same information. This is usefull for controllers, as they shouldn't store data anyway.
A prototype scope is the same as initialitzing an object with new, as it is created every time you inject it. We don't use this at all at the moment.
Related
I am learning Spring, I learned about bean scopes - what are the real world use cases for each of them, I am not able to get any help. please help when to use Singleton, Prototype , Request and Session scopes in Spring.
Singleton: It returns a single bean instance per Spring IoC container.This single instance is stored in a cache of such singleton beans, and all subsequent requests and references for that named bean return the cached object. If no bean scope is specified in the configuration file, singleton is default. Real world example: connection to a database
Prototype: It returns a new bean instance each time it is requested. It does not store any cache version like singleton. Real world example: declare configured form elements (a textbox configured to validate names, e-mail addresses for example) and get "living" instances of them for every form being created
Request: It returns a single bean instance per HTTP request. Real world example: information that should only be valid on one page like the result of a search or the confirmation of an order. The bean will be valid until the page is reloaded.
Session: It returns a single bean instance per HTTP session (User level session). Real world example: to hold authentication information getting invalidated when the session is closed (by timeout or logout). You can store other user information that you don't want to reload with every request here as well.
GlobalSession: It returns a single bean instance per global HTTP session. It is only valid in the context of a web-aware Spring ApplicationContext (Application level session). It is similar to the Session scope and really only makes sense in the context of portlet-based web applications. The portlet specification defines the notion of a global Session that is shared among all of the various portlets that make up a single portlet web application. Beans defined at the global session scope are bound to the lifetime of the global portlet Session.
Some one please me to find out the spring mvc examples,
Because usually, once we log in into the application we will create a session and put some objects into session . we will access later point of time , request scope as well. but spring MVC3 is difficult to understand even documentation also confusing, but every one giving example is basic examples only.
You can access these objects in a JSP/JSTL:
applicationScope
cookie
header
headerValues
initParam
pageContext
pageScope
param
paramValues
requestScope
sessionScope
As well as any request attributes that you add, including model attributes (who's default name is command).
More info here: http://www.informit.com/articles/article.aspx?p=30946&seqNum=7
If you want to access HttpRequest, HttpResponse, HttpSession, add them as arguments to a Spring Controller Handler Method . Spring will pass them in for you.
I deployed a web application on the localhost GlassFish server. This application takes order information from user and stores it in a List type variable in a Stateless Session Bean.The list object is created in the constructor.
I open the order page and add multiple orders in it. When I open the show orders page in different tabs and different browsers, it displays all the order information bean correctly, as though the state is maintained in a Stateless Bean!
I think this behavior is wrong as each browser/tab should create different session with the server and new order information should be shown for each browser/tab. How can this behavior be explained?
Your use case is precisely what a stateful session bean is for, if you want your List object to be maintained across method invocations, and if you want each session to be assigned its own bean.
Stateless session beans are pooled and made available to any session. But your instance fields are not guaranteed to be cleared, so you can't depend on them being cleared. The behavior that you are seeing is not unexpected. Even if you were successful in creating separate sessions in multiple tabs, those sessions could very well have been (and apparently were) assigned the same session bean. That's because the associated method invocations occurred at different points in time. Now if the associated method invocations occurred simultaneously instead, then the platform would have assigned a different stateless bean to each invocation (session). In that case, you'd see different behavior.
See also;
conversational state of session beans
and
Stateless and Stateful Enterprise Java Beans
Never let what you can't do get in the way of what you can do.
Problem: Stateful Session Bean was not maintaining separate state per client. In the example I tried, I input orders from the JSP page, which were stored in a List in a Stateful Session Bean. When I called the same URL from a different browser (i.e. a different session), the list of orders input in the previous session were visible. The same EJB was getting referenced in both sessions. (Verified by sysouts)
It's like saying, the shopping cart of some other user was directly visible to me as if they were my orders!!
Solution: Used an HttpSessionListener and got the dependency of the Stateful EJB through JNDI, in sessionCreated(HttpSessionEvent se) method. Next, added the stateful EJB in an HttpSession and accessed the EJB through session in servlet.
Suggestions for using JNDI, instead of DI, for Stateful Session Bean and Adding EJB to HttpSession are given in the answer above. Don't know if it is the proper way to go, but it works!!
I need to do forEach over lazy collection in jsp from spring controller. But this invocation crashes because session was closed in controller. I solve this by loding collection via:
Hibernate.initialize(obj.getCollection())
Is it possible to tune mvc to have hibernate session inside jsp?
Thanx
But this invocation crashes because session was closed in controller
I assume by crash you mean that you caused a LazyInitializationException by accessing a mapped collection after the session was closed.
Tuning mvc to have Hibernate session inside you JSP essentially means that you want to hold the session open for the duration of your HTTP request. This means that at render time you can still load the data you require.
You can achieve this using the open session in view pattern. In Spring this is implemented using the OpenSessionInViewFilter. See this answer for more detail on setting it up.
The alternative as you have already demonstrated it to load the data that you require within the transaction which loaded the parent. This is why Hibernate supports lazy loading. Sometimes you will need to load child entities and collections but sometimes you don't. By mapping it as lazy you can choose depending on the specific interaction.
We need to use multiple datasources in grails application. Per user i.e per each http session (from login to logout of user) the application takes different datasource based on the user's request.
http://www.leebutts.com/2008/07/switchable-grails-datasource.html
The above link provides a good solution for this. We have implemented as said in that page, with modified dynamic configuration.It's working well.
1) But how this code switches the datasource from session to session?
2) What is the use of ThreadLocal contextHolder in this code?
Please explain . . .
Thank you.
Grails binds requests to threads. A ThreadLocal variable holds a different value for each thread that accesses it (allowing thread safety without synchronization).
So, in his flow what happens is this:
User selects an Environment in the EnvironmentController, which the controller saves into the user's session.
The beforeFilter he has looks at each request and determines if there is an Environment in the user's session. If so, he sets the EnvironmentHolder to point to that environment. Since this is a ThreadLocal, each thread (in this case: request) can have it's own value.
When the dataSource bean is accessed, his SwitchableDatasource bean selects the correct datasource based upon the value held in the EnvironmentHolder's ThreadLocal value.