I am working on a weam web application where the once the user logs in, the main (or landing) page calls 4 stateful session beans. So once the user logs in, there will be atleast 4 threads of stateful session beans created. The page also has a logout button. The logout component in the xhtml calls a POJO which has a logout method.
In the logout method, the following statement is executed:
Session.instance().invalidate();
Now the question is, will the 4 threads/instances of the stateful session beans which are created when the user logs in will be destroyed or not.
I am running this application on JBOSS 4.2.3, Seam 2.2.1 Final
I am using JOSSO for authentication.
Yes, they're all part of the same session. You're actually creating session scoped beans, not separate sessions.
Easy enough to check though. Create a method in each of the session beans and annotate them with #Destroy, when the annotated bean is destroyed, it will call this method.
#Destroy
public void callMeWhenIDie(){
log.debug("I'm melting, I'm melting" + this.someDefiningCharacteristic);
}
Related
I am using Struts 2 v 2.3.16.3 with tomcat 6.
A user will click on an action which finds an object by id and the page displays it. I have encountered a sporadic bug where the user will all of a sudden get the id of another lookup from another user on another machine. So effectively they are both calling the same action but passing different id to the request, but both end up viewing the same id.
This is obviously disastrous, and the data is totally corrupted as both users think they are editing a different record. Any ideas how make sure session/request activity is kept secure to each session?
I am also using spring and am using the #Transactional annotation in my Service layer, which returns the objects from the DAO. Is there something I need to do with this annotation to make it secure for each session ?
I am using org.springframework.orm.hibernate3.HibernateTransactionManager
Classic Thread-UnSafe problem.
Since you nominated Spring, my first guess is that you have not specified the right scope for your action beans in Spring xml configuration.
Be sure you are using scope="prototype" because otherwise the default scope of Spring is Singleton, and you don't want a single(ton) instance of an Action, that would not be ThreadLocal (and hence ThreadSafe) anymore.
If it is not that, it could be something on an Interceptor (that, differently from an action, is not Thread Safe), or you are using something static (in your Business / DAO layer, or in the Action itself) that should be not.
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 have a backing session scope bean called WorkSession. When instance of this bean is created I call initialization function (declared with #PostConstruct annotation), which changes current user (I handle user logging with JASS) status in database to ONLINE.
I want to do analogical thing when user logs out (change user status to OFFLINE). It is easy to do this when user presses button "Logout" on web page. The problem is that i have no idea how to detect closed browser or tab in browser.
I see that method with annotation #PreDestroy does not work for this, because it's called by application server garbage collector, right?
I use Glassfish 3.1.2, JPA 2,0 and JSF 2.0.
I see that method with annotation #PreDestroy does not work for this, because it's called by application server garbage collector, right?
It should work just fine. It's absolutely not called by the GC. It's called by the container when the session is destroyed. Perhaps your concrete problem is that you expected that the session is immediately destroyed when the user closes the entire browser. This is thus not true. It's only destroyed when it's timed out in the server side. The default timeout is 30 minutes. So if you wait 30 minutes, then the session will be destroyed and the #PreDestroy of all session (and view) scoped beans will be called.
You can configure the default timeout by <session-config><session-timeout> in web.xml.
See also:
How do servlets work? Instantiation, sessions, shared variables and multithreading - to learn how sessions work "under the covers".
By the way, the term "session disconnect" makes absolutely no sense in web development world.
I'm using Spring 3.1.1.Release, Security 3.1.0.Release.
I've added login/logout to my web app, however a session scoped bean is not functioning the way it was. The bean is used to connect to a CMS called CMSConnector.
To authenticate users, I implemented an AuthenticationProvider, and in the authenticate() call, I get the session-scoped CMSConnector and call the CMSConnector.login(). If the CMS login fails, it fails the login.
THE PROBLEM -
If the login is success, #predestroy logout() is called immediately after the successful login. I then found it was the SessionFixationProtectionStrategy is invoking the invalidate the previous session and assign it a new session.
session.invalidate();
session = request.getSession(true); // we now have a new session
The invalidate() is calling the #predestroy method on the session-scoped bean.
So I have temporarily removed the the #predestroy annotation leaving the connection not closed. (VERY BAD PRACTICE.)
What is a work around to resolve the issue?
I tried to create a #PostConstruct and put the login process there, but the #PostConstruct doesn't get called when request.getSession(true) is called.
Thanks!
Jason
I think its not the SessionFixationProtectionStrategy but the ConcurrentSessionControlStrategy.
Set max-sessions="-1" for this code snippet
I did not solve my original question, but I implemented a workaround - expire session in the session expire object instead of attached with #predestroy.
I want to know about setting and un-setting the session in JSF2.0. Although following some blogs and books (Core JavaServer Faces-3rd Edition), i got to know that using annotation #SessionScoped we can set any manage bean to be in session. I have a loginBean which is #ManagedBean and SessionScoped declared. On the top right corner, my web has login button.
When this session is created (i am not setting it manually, that is why i am confused) and when i gets destroyed? It must be destroyed either by time out or by clicking in logout button only.
JSF uses the Servlet API under the covers. A session scoped managed bean is in essence set as an attribute of the HttpSession. It will be created and set whenever the EL expression referencing the managed bean #{sessionBean} is evaluated for the first time. It will be "removed" from the session whenever the session expires (by either a restart of the client or a timeout in the server) or get invalidated. If you let your logout button call ExternalContext#invalidateSession(), then the session will be invalidated.
If you're familiar with the basic Servlet API, you should already understand how this all works. For an in-depth explanation of the Servlet's HttpSession works under JSF's covers, read this answer: How do servlets work? Instantiation, sessions, shared variables and multithreading.
In jsf 2.0 we can set total class ob as session like i mention
Class_name sm;
ExternalContext extContext = FacesContext.getCurrentInstance().getExternalContext(); extContext.getSessionMap().put("Give name for access this property",sm);
Class_name sm = (Class_name) extContext.getSessionMap().get("Give name for access this property");