Serialization of HttpSessions

Section 7.7.2 of the 2.4 Servlet spec says that developers are not guaranteed that containers will call readObject and writeObject methods on session attributes but are guaranteed that the Serializable closure of their attributes will be preserved. Can someone please explain what this means. If I have implemented serialization on a class using readObject/writeObject am I not able to place objects of the class in the session and know that serialization will work?

I think that the specification is refering to the servet class itself, not classes you build.
MeTitus

Similar Messages

Session replication exception

 hi all
 I am getting the exception below on the second server in
 the cluster when i am hitting the first machine whenever
 i am trying to login.
 My config.xl is such that the session is replicated;
 Also i am attaching an object of NWSession( implements serializable ) to HttpSession
 object.
 Both servers in the cluster are identical and has the
 same web applications deployed ( so that the class
 com.epeople.NWSession class is available on both
 servers ) ( Note that i can create an instance of
 NWSession on both servers )
 Thanks in advance,
 sri kumar
 java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
 java.lang.ClassNotFoundException: com.epeople.nwsession.NWSession
 java.lang.ClassNotFoundException: com.epeople.nwsession.NWSession
 <<no stack trace available>>
 --------------- nested within: ------------------
 weblogic.rmi.extensions.RemoteRuntimeException - with nested exception:
 [java.rmi.UnmarshalException: error unmarshalling arguments; nested exception
 is:
 java.lang.ClassNotFoundException: com.epeople.nwsession.NWSession]
 at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:60)
 at $Proxy131.create(Unknown Source)
 at weblogic.cluster.replication.ReplicationManager.trySecondary(ReplicationManager.java:797)
 at weblogic.cluster.replication.ReplicationManager.createSecondary(ReplicationManager.java:743)
 at weblogic.cluster.replication.ReplicationManager.getPrimary(ReplicationManager.java:716)
 at weblogic.cluster.replication.ReplicationManager.lookup(ReplicationManager.java:374)
 at weblogic.servlet.internal.session.ReplicatedSessionContext.getSessionInternal(ReplicatedSessionContext.java:271)
 at weblogic.servlet.internal.ServletRequestImpl.getValidSession(ServletRequestImpl.java:1888)
 at weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.java:1697)
 at weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(ServletSecurityManager.java:119)
 at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2367)
 at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:1959)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)


 I am having the same problem. I am even running both servers in the cluster on
 the same machine (using multi homing ) and still get this error . Any help , please
 . Any BEA expert ??
 "Narinder" <[email protected]> wrote:
 >It looks like, NWSession is not visible to the second server. Try making
 >sure that the config on the second server is exactly like the first server.
 >-Narinder
 >
 >
 >"Sri kumar" <[email protected]> wrote in message
 >news:[email protected]...
 >>
 >> hi all
 >>
 >> I am getting the exception below on the second server in
 >> the cluster when i am hitting the first machine whenever
 >> i am trying to login.
 >>
 >> My config.xl is such that the session is replicated;
 >>
 >> Also i am attaching an object of NWSession( implements serializable
 >) to
 >HttpSession
 >> object.
 >>
 >> Both servers in the cluster are identical and has the
 >> same web applications deployed ( so that the class
 >> com.epeople.NWSession class is available on both
 >> servers ) ( Note that i can create an instance of
 >> NWSession on both servers )
 >>
 >> Thanks in advance,
 >> sri kumar
 >>
 >> java.rmi.UnmarshalException: error unmarshalling arguments; nested
 >exception is:
 >>
 >> java.lang.ClassNotFoundException: com.epeople.nwsession.NWSession
 >> java.lang.ClassNotFoundException: com.epeople.nwsession.NWSession
 >> <<no stack trace available>>
 >> --------------- nested within: ------------------
 >> weblogic.rmi.extensions.RemoteRuntimeException - with nested exception:
 >> [java.rmi.UnmarshalException: error unmarshalling arguments; nested
 >exception
 >> is:
 >> java.lang.ClassNotFoundException: com.epeople.nwsession.NWSession]
 >> at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:60)
 >> at $Proxy131.create(Unknown Source)
 >> at
 >weblogic.cluster.replication.ReplicationManager.trySecondary(ReplicationMana
 >ger.java:797)
 >> at
 >weblogic.cluster.replication.ReplicationManager.createSecondary(ReplicationM
 >anager.java:743)
 >> at
 >weblogic.cluster.replication.ReplicationManager.getPrimary(ReplicationManage
 >r.java:716)
 >> at
 >weblogic.cluster.replication.ReplicationManager.lookup(ReplicationManager.ja
 >va:374)
 >> at
 >weblogic.servlet.internal.session.ReplicatedSessionContext.getSessionInterna
 >l(ReplicatedSessionContext.java:271)
 >> at
 >weblogic.servlet.internal.ServletRequestImpl.getValidSession(ServletRequestI
 >mpl.java:1888)
 >> at
 >weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.j
 >ava:1697)
 >> at
 >weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(Servle
 >tSecurityManager.java:119)
 >> at
 >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
 >ntext.java:2367)
 >> at
 >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
 >:1959)
 >> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
 >
 >

Pass a session to one project to another

i know that i have to use the HttpSessionActivationListener interface to do this job, but i can�t do it. i read that the object to be store in the container has to implment HttpSessionActivationListener anyone has an example?

here a typical code to test:
create a listener class as follows:package com.company.project.web.listener;
import java.io.Serializable;
import java.util.Hashtable;
import javax.servlet.http.HttpSession;
import javax.servlet.http.HttpSessionActivationListener;
import javax.servlet.http.HttpSessionEvent;
public class MySessionsListener implements HttpSessionActivationListener{
 public static Hashtable<String, SessionBean> sessionMap = new Hashtable<String, SessionBean>();
 public void sessionDidActivate(HttpSessionEvent event) {
 HttpSession session = event.getSession();
 updateSessionMap(session, true);
 public void sessionWillPassivate(HttpSessionEvent event) {
 HttpSession session = event.getSession();
 updateSessionMap(session, false);
 private void updateSessionMap(HttpSession session, boolean isActive){
 sessionMap.put(session.getId(), new SessionBean(session, isActive));
 class SessionBean implements Serializable{
 private HttpSession session;
 private boolean isActive = false;
 public SessionBean(){}
 public SessionBean(HttpSession session, boolean isActive){
 this.session=session;
 this.isActive=isActive;
 * Gets all the sessions (acive and passive)
 * @return
 public static Hashtable getSessionMap(){
 return sessionMap;
}add the to your web.xml file:
 <listener>
 <listener-class>com.company.project.web.listener.MySessionsListener</listener-class>
 </listener>You can get all the current sessions (active ad passive) anywhere in you code using:
MySessionsListener.getSessionMap();hope it helps

Is WL6's ServletContext and HttpSession implementation Serializable?

As the subject stated
          Rgds,
          Raymond Mok


No, they are not serializable.
          mark
          Raymond Mok wrote:
          > As the subject stated
          >
          > Rgds,
          > Raymond Mok

Serialization vs. HttpSession

Hi,
 Does HttpSession store an object's state the same way that an object
 becomes serialized?
 This is only interesting to me because I am trying to use the transient
 modifier to NOT save any instance variables I don't want to persist in
 the session. However, as some of you may already, it does not work
 regarding to sessions.
 Basically, I want some instance variables (both of primitive or Object
 type) to become instantiated with the defaults given in the global area.
 However, since, I get the instance from the session, it returns me the
 state it was right before I put in the session.
 e.g.
 //A member field of MyClass instantiated in the global area.
 public class MyClass {
 public int foo = 9;
 //in a jsp
 MyClass myClass = new MyClass();
 myClass.foo = 100;
 session.putValue("MyClass", myClass);
 MyClass test=(MyClass)session.getValue("MyClass");
 System.out.println(test.foo); //will print out 100. however I want this
 //to default to 9.
 I hope the example helps what I'm trying to say/do. Please respond if
 you have any input/info.
 Thanks.
 Janssen Wee
 WhatsHotNow.com


I believe you are probably using in-memory sessions so the sessions are
 never flattened which is why the transient modifier has no effect.
 I think you would get your expected behavior if you were using session
 persistence or replication. For example, If you used file-based session
 persistence, I believe that after each http request the session is
 serialized and written to disk and when the session is rejoined you would
 see the effect of transient member variable. You will also see this if you
 are doing session replication accross a cluster, the failover partner would
 only have the non-transient state of the session.
 -paul
 Janssen Wee <[email protected]> wrote in message
 news:[email protected]...
 > Hi,
 >
 > Does HttpSession store an object's state the same way that an object
 > becomes serialized?
 >
 > This is only interesting to me because I am trying to use the transient
 > modifier to NOT save any instance variables I don't want to persist in
 > the session. However, as some of you may already, it does not work
 > regarding to sessions.
 >
 > Basically, I want some instance variables (both of primitive or Object
 > type) to become instantiated with the defaults given in the global area.
 > However, since, I get the instance from the session, it returns me the
 > state it was right before I put in the session.
 >
 > e.g.
 > file://A member field of MyClass instantiated in the global area.
 > public class MyClass {
 > public int foo = 9;
 > ...
 > }
 >
 > file://in a jsp
 >
 > MyClass myClass = new MyClass();
 > myClass.foo = 100;
 > session.putValue("MyClass", myClass);
 > ...
 > MyClass test=(MyClass)session.getValue("MyClass");
 > System.out.println(test.foo); file://will print out 100. however I want
 this
 > file://to default to 9.
 >
 > I hope the example helps what I'm trying to say/do. Please respond if
 > you have any input/info.
 >
 > Thanks.
 >
 > Janssen Wee
 > WhatsHotNow.com

HttpSession invalidate issue + serialization

The set up of my code is as follows:
* Applet communicates with Servlet(s)
* ServletA keeps a HashMap of session objects with an attribute as key.
* Once logout is called in applet - a call comes to servlet in form of a seriallized request object.
* After sessions is invalidated, second line of code is to send back a serialized response object back
* This is where I receive what seems to be a java.io.EOF exception
Reading up on invalidate() didn't seem to shed any light on anything similar happening except for the fact that the object's bindings are lost. Would that mean that I am not able to write on the response from servlet back to applet once I destroy session inside sevlet??
Thank you in advance.

My code here:
HttpSession session = this.getRequest().getSession();This is the current session. The new one.
//sessionID - getting existing session ID from DBHow you get this is unstated, but let that pass.
HttpSession oldSession = (HttpSession)session.getAttribute(sessionID);As I said before, this is nonsense. How can the old session possibly get into the attributes of the new session? Who put it there? Magic? What makes you think a session is available by sessionID from any servlet API at all? Hint: it isn't.
oldSession.invalidate(); //getting exception hereTrivially that's because 'oldSession' is null and you're not even checking it. You should have figured that out for yourself. You don't seem to have even considered the possibility that it is null, let alone the probability that the reason is that the previous line of code which set it is invalid. Instead you are just asking for a workaround to make your preconceived code work, when what you should be doing is asking about the validity of your preconceptions.
I find all that pretty strange frankly.
I also find the underlying requirement pretty strange. What if the user is logged in at two workstations simultaneously? Logging in at the second one will forcibly log him out of the first one. Why?

Urgent: Problems with HttpSessions in weblogic 5.1

Hi,
          I am work with Weblogic 5.1, Service Pack 9. I use servlets and
          HttpSession together. The idea is to store shared info in the session. I
          insert complex objects, which implements Serializable interface, in the
          session and SOMETIMES when I try to extract this object casting the
          object to the real class I encounter an Exception:
          action:
          permisosPortal=(EstructuraPermisosPortal)sesion.getAttribute(portal);
          portal value is "pruebas"
          result:
          Message,
          java.lang.ClassCastException:
          com.administracion.modeloGestionSeguridad.EstructuraPermisosPortal
          Trace,
          java.lang.ClassCastException:
          com.administracion.modeloGestionSeguridad.EstructuraPermisosPortal
          at
          com.administracion.modeloGestionSeguridad.Autenticacion.permisosAdquiridos(Autenticacion.java:41)
          at
          com.administracion.novedadesServlet.FormularioAltaNovedadesServlet.service(FormularioAltaNovedadesServlet.java:47)
          at
          javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
          at
          weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:915)
          at
          weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:879)
          at
          weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
          at
          weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:365)
          at
          weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:253)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)
          I don't know where is the problemm because if I introduce a
          System.out.println before this sentence it never crashes.
          action:
          System.out.println(sesion.getAttribute(portal).getClass().getName()+"
          "+sesion.getAttribute(portal));
          result:
          no crash.
          Could anyone help me?
          Thanks.


Hi,
          I am work with Weblogic 5.1, Service Pack 9. I use servlets and
          HttpSession together. The idea is to store shared info in the session. I
          insert complex objects, which implements Serializable interface, in the
          session and SOMETIMES when I try to extract this object casting the
          object to the real class I encounter an Exception:
          action:
          permisosPortal=(EstructuraPermisosPortal)sesion.getAttribute(portal);
          portal value is "pruebas"
          result:
          Message,
          java.lang.ClassCastException:
          com.administracion.modeloGestionSeguridad.EstructuraPermisosPortal
          Trace,
          java.lang.ClassCastException:
          com.administracion.modeloGestionSeguridad.EstructuraPermisosPortal
          at
          com.administracion.modeloGestionSeguridad.Autenticacion.permisosAdquiridos(Autenticacion.java:41)
          at
          com.administracion.novedadesServlet.FormularioAltaNovedadesServlet.service(FormularioAltaNovedadesServlet.java:47)
          at
          javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
          at
          weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:915)
          at
          weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:879)
          at
          weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
          at
          weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:365)
          at
          weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:253)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)
          I don't know where is the problemm because if I introduce a
          System.out.println before this sentence it never crashes.
          action:
          System.out.println(sesion.getAttribute(portal).getClass().getName()+"
          "+sesion.getAttribute(portal));
          result:
          no crash.
          Could anyone help me?
          Thanks.

NoClassDefFoundError when passing HttpSession

Hello All,
I am getting a NoClassDefFoundError when I start my rmi server.
I am pass an HttpSession as one of the variables of my rmi call.
Everything worked fine until I added the HttpSession variable.
Why do I get this exception ?
Exception in thread "main" java.lang.NoClassDefFoundError: javax/servlet/http/Ht
tpSession
 at java.lang.Class.getDeclaredMethods0(Native Method)
 at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
 at java.lang.Class.privateGetPublicMethods(Class.java:2519)
 at java.lang.Class.getMethods(Class.java:1406)
 at sun.rmi.server.Util.getRemoteInterfaces(Util.java:221)
 at sun.rmi.server.Util.getRemoteInterfaces(Util.java:193)
 at sun.rmi.server.Util.createProxy(Util.java:126)
 at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:169)
 at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:293)
 at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:235)
 at java.rmi.server.UnicastRemoteObject.<init>(UnicastRemoteObject.java:133)
 at java.rmi.server.UnicastRemoteObject.<init>(UnicastRemoteObject.java:119)
 at pE.PEg.<init>(PEgImpl.java:36)
 at pE.PEgServer.<init>(PEgServer.java:10)
 at pEngine.PEgServer.main(PEgServer.java:18)If I add server2_2.jar to my class path, then I get this exception:
java.rmi.ServerError: Error occurred in server thread; nested exception is:
 java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionWhile were at it, let me ask this: My RMI implementation code has some data that it needs to pass to my servlet that is invoked by an third-party server. I due to the sensitive nature of the data, I don't want to stick it in a DB, but pass as session variables, thus I was passing in the session var. A better way to do this?
Edited by: jimcsc on Aug 29, 2008 9:58 AM

I am getting a NoClassDefFoundError when I start my rmi server.That will be because either the server or the Registry or the client doesn't have the class named in the exception in its CLASSPATH.
I am pass an HttpSession as one of the variables of my rmi call.Are HttpSessions really serializable? This sounds like a very odd design.
While were at it, let me ask this: My RMI implementation code has some data that it needs to pass to my servlet that is invoked by an third-party server. I due to the sensitive nature of the data, I don't want to stick it in a DB, but pass as session variables, thus I was passing in the session var.There's something wrong with that description. It seems to me that it is the servlet passing the HttpSession to your RMI server, not the other way around. Assuming the HttpSession implementation is serializable it should work but it's still an odd design. I would get the stuff that you actually need out of the HttpSession and pass that.

Is a Servlet-Filter which serializes requests in the same user session ok?

The Servelt specification states that the Web-Application is itself responsible for synchronizing access to HttpSessions. It is from the serversite not possible to prevent multiple threads to access the same HttpSession (i.e. the user could always open a second window, retransmit a form etc). My assumption is that while this does not happen often it can happen and therefore I think each access to the HttpSession must be synchronized. For a further discussion see http://forum.java.sun.com/thread.jsp?forum=4&thread=169872 .
Concurrent programming is generally complicated and errorprone. At least in developing JSPs it is inconvenient and easy to forget. My Web-App uses often HttpSession and it can be used in different not predefined places, so I had the idea to implement a ServletFilter which serializes threads which happen in the same session. This involves certainly some overhead. However for the advantages of easier code maintains and higher consistency I am ready to pay this overhead.
My question is generally what you think of this approach and second whether the way I implemented the Filter works.
The Filter actually generates for each Request an HttpServletRequestWrapper which intercepts calls to getSession and on call aquires a Lock so that other threads have to wait for the same Session. The lock is released when the doFilter method of the Filter returns. So threads run concurrently until the first access to the Session and from there they are serialized until the end of the Request.
For the details I will give the code for the Filter and the Wrapper (that?s all the code needed except the ReentrantLock which is Doug Lea?s implementation http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html )
the Filter
public class SessionThreadFilter implements Filter
public static final String MUTEXT_IN_SESSION_KEY = "org.jaul.filter.SessionThreadFilter.MUTEX";
//constructor, init, destroy methods do nothing
public void doFilter(ServletRequest reqIn,ServletResponse res,FilterChain filterChain)
    throws IOException, ServletException
    //if req not instanceof of HttpRequest don't do anything
    if (!(reqIn instanceof HttpServletRequest))
      filterChain.doFilter(reqIn, res);
    } else
      HttpServletRequest req = (HttpServletRequest) reqIn;
      //We use a HttpRequestWrapper each time a user accesses
      //through this
      //Wrapper a Session is Lock is aquired. The filter method returns
      //the lock if it exists is released
      //each thread needs it's own wrapper so the wrapper itself
      //doesn't have to be synchronized
      SessionThreadRequestWrapper wrapper = new SessionThreadRequestWrapper(req);
      try{
        filterChain.doFilter(wrapper, res);
      }finally{
        ReentrantLock lock = wrapper.getLock();
        if (lock != null && lock.holds() != 0)
                   lock.release(lock.holds());
the Wrapper
final public class SessionThreadRequestWrapper extends HttpServletRequestWrapper {
private ReentrantLock lock = null;
   * Constructor for SessionThreadRequestWrapper.
   * @param arg0
public SessionThreadRequestWrapper(HttpServletRequest req){
    super(req);
   * @see javax.servlet.http.HttpServletRequest#getSession()
public HttpSession getSession(){
    return getSession(true);
   * @see javax.servlet.http.HttpServletRequest#getSession(boolean)
public HttpSession getSession(boolean construct){
    //this will get the session an the lock
    HttpSession session = getLockFromSession(construct);
    if (session == null) return null;
    //get a lock on the mutex
    try{
      lock.acquire();
    } catch (InterruptedException e){
      throw new IllegalStateException("Interrupted while thread waiting for session");
    //now we check again if the session is still valid
    try{
      session.getAttribute(SessionThreadFilter.MUTEXT_IN_SESSION_KEY);
    } catch (IllegalStateException e){
      //again we go recusively but first release the lock
      lock.release();
      lock = null;
      return getSession(construct);
    //after you got the lock you can return the session
    return session;
   * gets the lock from the session
   * @param construct
   * @return HttpSession
private HttpSession getLockFromSession(boolean construct){
    //test if it is a new Session
    HttpSession session = super.getSession(construct);
    //if is null no session was realy requested
    if (session == null) return null;
    //otherwise try to get the lock if necessery construct it
    //syncrhonized over session
    synchronized (session){
      //this migth throw an Exception if the session has been
      //invalidated in the mean time
      try{
        lock = (ReentrantLock) session.getAttribute(SessionThreadFilter.MUTEXT_IN_SESSION_KEY);
        if (lock == null){
          lock = new ReentrantLock();
          session.setAttribute (SessionThreadFilter.MUTEXT_IN_SESSION_KEY, lock);
        return session;
      } catch (IllegalStateException e){
        //the session has been invalidated before we tried to get the
        //lock we recursively call getLockFromSession
        //( assumption checked with Jetty: if the session is invalidated
        //and getSession is called on the thread a new valid session
        // should is returend)
        //I hope sometime you should get a valid session but I am not
        //sure. This is crucial for breaking of the recursion
        lock = null;
        return this.getLockFromSession(construct);
/** used by the Filter to get the lock so that it can release it
ReentrantLock getLock(){
     return this.lock;
}As stated I would be very thankful if you could check the code and give some commends.

synchronized (session){Are you sure that the session instance returned by two
concurrent calls to getSession(...) are the same? I
think that tomcat for instance may return different
instances for the same "logical " session, which would
break your scheme I think... Thank you (I did not know that on Tomcat). The same thing could also occur if another filter wrapped the Session.
That's indeed a problem,which I have already adressed in another thread, but did not get an answer. ( http://forum.java.sun.com/thread.jsp?forum=33&thread=412380). The already cited thread http://forum.java.sun.com/thread.jsp?forum=4&thread=169872 adresses the same problem, but the discussion there ends with the recomandation that you should synchronize on HttpSession as I did it. Also in other forums I've read so.
However like you I've at least strong doubts in this approach, so now my question is on what should I than generally for any access in any web-app syncrhonize the access to Http-Session as demanded by the Servlet specs.
A few not realy satisfying answers:
Synchronize on the HttpSession itself: I think still the best approach, but as you say is it guaranteed that the same instance of an HttpSession is given to each Request (in one Session)?
Synchronized on the HttpServlet: This only works if no other servlet (or jsp) accesses in the session the value with the same key ( of course only if the session itself is threadsave). In case of ThingleThread it is not possible at all there can be multiple instances (you could use a static variable)
Holding the object to synchronize on in applicaton scope or session scope: This obiously doesn't help, because somehow you have to obtain the lock and at least there you need another synchronize.Holding in application socpe is slow a static variable lock would be better there.
Synchronize on some static variable: This will work, but is very slow (each request not only in the same session would synchronize on this).
Hold a map in application scope, which holds for each Session-key a lock: Is probably faster than the static variable thing. However the access and the management of the Map (removing of unused locks etc.- Mabe you could use a WeakHashMap to collect the locks for not used keys anymore) is time consuming too and again the map must be accessed syncrhonasly by all requests.
Syncrhonize on the Filter (only in my case): This is as slow as the static variable approach because each request will use the same lock the one instance of the Filter.
So synchronizing on the session is propably the best approach if the same attribute name is accesed by different servlets. However if you say that some Web-Containers return different HttpSession instances for the same Session (which is legal according to the specification) this of course does not work.
So I have realy no clue on what to syncrhonize than. Now help is not only neede on my Thread serialization filter but on my generally Servlet prgromming.
May be you could help me for another synchronization aproach.

How do I ensure HttpSession state is NOT persisted across server failures?

 I need to PREVENT the data in the HttpSession from being restored if the server crashes.
 I can't seem to find any documentation explicitly documentating how to ensure this.
 Any help would be greatly appreciated.
 Thanks,
 Andrew
 (p.s. this applies to WL5.1sp8 and WL6.1sp2)


WebLogic doesn't serialize and restore sessions when the server is
 shutdown/crashes
 for "memory" sessions. That should not happen. Check the value of
 session.getClass()
 to verify the perisistentStoreType.
 --Vinod.
 "Andrew Larson" <[email protected]> wrote in message
 news:[email protected]...
 >
 > It is set to memory, but it appears to serialize and restore most of the
 sessions
 > when the server is shutdown/crashes. It there a way to set the
 persistence to none?
 > (e.g. in memory, not replicated, and only for the lifetime of the JVM)
 >
 > "Vinod Mehra" <[email protected]> wrote:
 > >What's your persistentStoreType (in weblogic.xml) set to?
 > >
 > >It seems you want persistentStoreType="memory" (which is the default).
 > >
 > >Is that what you are looking for?
 > >
 > >--Vinod.
 > >
 > >
 > >"Andrew Larson" <[email protected]> wrote in message
 > >news:[email protected]...
 > >>
 > >> Yes, in both instances (crash or graceful shutdown) I need session
 state
 > >cleared away.
 > >> This doesn't seem to be happening.
 > >>
 > >> Help please!
 > >> TIA
 > >> Andrew
 > >>
 > >>
 > >> "Vinod Mehra" <[email protected]> wrote:
 > >> >Oh, yes I misread your question. Do you want your sessions to be
 cleaned
 > >> >up
 > >> >even on a graceful server shutdown too?
 > >> >
 > >> >--Vinod
 > >> >
 > >> >
 > >> >"Andrew Larson" <[email protected]> wrote in message
 > >> >news:[email protected]...
 > >> >>
 > >> >> you don't seem to understand - I do NOT want session state to last
 > >> >across a server
 > >> >> crash; I want the session state to be lost, cleared away, gone,
 never
 > >> >to
 > >> >be seen
 > >> >> again.
 > >> >>
 > >> >>
 > >> >> "Vinod Mehra" <[email protected]> wrote:
 > >> >> >Use session persistent store types: replicated or file or jdbc.
 > >> >> >
 > >> >> >Please refer to the docs for details.
 > >> >> >
 > >> >> >--Vinod.
 > >> >> >
 > >> >> >
 > >> >> >"Andrew Larson" <[email protected]> wrote in message
 > >> >> >news:[email protected]...
 > >> >> >>
 > >> >> >> I need to PREVENT the data in the HttpSession from being restored
 > >if
 > >> >the
 > >> >> >server crashes.
 > >> >> >> I can't seem to find any documentation explicitly documentating
 > >how
 > >> >to
 > >> >> >ensure this.
 > >> >> >>
 > >> >> >> Any help would be greatly appreciated.
 > >> >> >> Thanks,
 > >> >> >> Andrew
 > >> >> >> (p.s. this applies to WL5.1sp8 and WL6.1sp2)
 > >> >> >
 > >> >> >
 > >> >>
 > >> >
 > >> >
 > >>
 > >
 > >
 >

ReportEngine (XI-R3.1) is not Serializable and fails on a wbelogic cluster

In our J2EE web-application we store <code>com.businessobjects.rebean.wi.ReportEngines</code> in the <code>HttpSession</code> as recommended.
 From this instance we retrieve the appropriate report "<code>ReportEngine</code>" instance based on the storeagetoken.
 We retrieve the ReportEngine instance by:
 
 <code>ReportEngine reportEngine = reportEngines.getServiceFromStorageToken(strEntry);</code>
 
 The above works in a non-clustered single application server environment (weblogic-10).
 
 But in a cluster, if the storage-token and "ReportEngines" are created in one Node, then we get a <code>null</code> when we try retrieving the <code>ReportEngine</code> in another node.
 
 We dug in and discovered out that while "<code>ReportEngines</code>" implements Serializable "<code>ReportEngine</code>" does not implement the same.
 
 We noticed that the .NET SDK implementation of "<code>ReportEngine</code>" is serializable though (unlike Java).
 
 Does anyone know of any patch for the above.
 
 We have worked around by serializing the <code>DocumentInstance</code>in the DB and retrieve this using teh storage-token itself as a key.
 Obviously, we use this route only as a workaround (only when we encounter a <code>null</code> <code>ReportEngine</code>,due the cluster node switches).
 
 ----
 There are other ways to get it to work without our workaround. One is by getting the load-balancer to retain the same weblogic node all thru the user-session (and in this case it works), but he cannot use that kind of a setup in our production environment.
 We have to have the loadbalancer distributing requests to all nodes in the cluster regadless to the session.
 --
 
 Would be glad to know of a SDK-patch for the above serialization issue.
Edited by: savincent on Aug 11, 2010 9:56 PM
Edited by: savincent on Aug 11, 2010 10:24 PM

There's no patch for that in the XI 3.1 and previous product line.
Your workaround sounds nice, i.e., sticky sessions for the session, and retrieve from token for failover. When retrieving from the storage token, it serializes the report back from the WebI Report Server.
Sincerely,
Ted Ueda

Oracle Coherence*Web and BlazeDS: Multiple FlexSessions created for the same HttpSession

Hi all,
I have searched this forum and found a lot of good information from Alex Glosband and others about the infamous "Detected duplicate HTTP - based FlexSessions, generally due to the remote host disabling session cookies. Session coolkies must be enable to manage the client connection correctly." message.
It seems, however, none of the cases are identical to ours. This is ours:
- Resin 3.1.9
- Oracle Coherence 3.7.1 with Coherence*Web (session replication)
With this setup we get the "Detected duplicate HTTP..." message on the first attempt to use BlazeDS and on every subsequent call. The same client and server code works fine in a local sessions setup. With Coherence 3.3 (currently our production environment) it seems to occur less frequently, but still as frequent as it is a major issue for us. It fails even with a single node using in-process distributed caching in our test setup (as well as with multi node out of process caching in our staging environment, for Coherence knowledgeable the resin app server runs with tangosol.coherence.session.localstorage=true in the first case and false in the second).
Both the listener and message broker are mapped as "Coherence aware" in web.xml[1] so that they should use clustered sessions.
We have been digging a bit and we found out that if we commented out lines 427 and 434 of flex.messaging.endpoints.BaseHTTPEndpoint from version 4.0.0.14931 it seems to mask the bug. We added some logging in the setupFlexClient method and it seems that we get more or less a new FlexSession for each and every call - but they have the same cookie and thus underlying HttpSession. I.e. the list returned from flexClient.getFlexSessions() keeps growing. Thus we are not so keen on going to production with that memory leak and the above mentioned ugly hack of commenting out the detection of duplicates.
We use request scope for the remote object, but could in theory use any scope as we do not really have any state on the object itself, it is all HttpSession state and return values that are key (logon is performed prior to doing the first blaze call, in pure forms and ajax, and it is not a timing issue in that regard we are seeing).
Hope someone can shed some light on what can be happening. Is there any "reference testing"[2] or something when the FlexSessions are created that makes them being created as new? Where are they created? We do not know the inner workings of the BlazeDS source, we just watched the call trace of the unwanted invalidation and found that to be line 427 of flex.messaging.endpoints.BaseHTTPEndpoint.
Can we disable FlexSessions? Since the flex and plain html parts of the app share the sessions, we always use FlexContext.getHttpRequest().getSession() anyway, never storing any state directly in the FlexSession or on the remote object. Or maybe there is a config option to help us with this detection (or creation) of multiple FlexSessions?
Cheers and TIA,
-S-
[1] - For instance, this i the message broker servlet def:
<servlet>
<servlet-name>MessageBrokerServlet</servlet-name>
<display-name>MessageBrokerServlet</display-name>
<servlet-class>com.tangosol.coherence.servlet.api22.ServletWrapper</servlet-class>
<init-param>
<param-name>coherence-servlet-class</param-name>
<param-value>flex.messaging.MessageBrokerServlet</param-value>
</init-param>
<init-param>
<param-name>services.configuration.file</param-name>
<param-value>/WEB-INF/flex/services-config.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
[2] - As you undertstand this is speculation based on pure air, but it could be that in Coherence there was a serialization/deserialization happening somehow that would break such a test?

Just a quick update, it seems things are running in a stable fashion (and without visible memory leaks, just keeping the latest FlexSession) with these changes in BaseHTTPEndpoint:
 * Overrides to guard against duplicate HTTP-based sessions for the same FlexClient which will occur if the remote host has disabled session
 * cookies.
 * @see AbstractEndpoint#setupFlexClient(String)
 @Override
 public FlexClient setupFlexClient(String id) {
 log.debug("setupFlexClient start id " + id);
 FlexClient flexClient = super.setupFlexClient(id);
 // Scan for duplicate HTTP-sessions and if found, invalidate them and throw a MessageException.
 // A request attribute is used to deal with batched AMF messages that arrive in a single request by trigger multiple passes through this
 // method.
 boolean duplicateSessionDetected = (FlexContext.getHttpRequest().getAttribute(REQUEST_ATTR_DUPLICATE_SESSION_FLAG) != null);
 if (!duplicateSessionDetected) {
 List<FlexSession> sessions = flexClient.getFlexSessions();
 log.debug("Client has " + sessions.size() + " sessions.");
 int n = sessions.size();
 if (n > 1) {
 int count = 0;
 for (int i = 0; i < n; i++) {
 if (sessions.get(i) instanceof HttpFlexSession)
 count++;
 if (count > 1) {
 FlexContext.getHttpRequest().setAttribute(REQUEST_ATTR_DUPLICATE_SESSION_FLAG, Boolean.TRUE);
 duplicateSessionDetected = true;
 break;
 // If more than one was found, remote host isn't using session cookies. Kill all duplicate sessions and return an error.
 // Simplest to just re-scan the list given that it will be very short, but use an iterator for concurrent modification.
 int i = 0;
 if (duplicateSessionDetected) {
 List<FlexSession> sessions = flexClient.getFlexSessions();
 log.debug("Detected sessions from client: " + sessions);
 for (FlexSession session : sessions) {
 if (session instanceof HttpFlexSession && i < sessions.size()) {
// log.debug("----> sessionId: " + session.getId());
// Enumeration e1 = session.getAttributeNames();
// while (e1.hasMoreElements()) {
// Object key = e1.nextElement();
// log.debug("--------->" + key + "--------->" + session.getAttribute((String) key));
// session.invalidate();
 flexClient.sessionDestroyed(session);
 i++;
 // Return an error to the client.
// DuplicateSessionException e = new DuplicateSessionException();
// e.setMessage(ERR_MSG_DUPLICATE_SESSIONS_DETECTED);
// throw e;
 return flexClient;
It is not exactly beautiful (to say the least), but if it does the trick I might just be pragmatic enough to go with it... NB: I am of course not proposing this as a patch to this file or anything, it is just an ugly hack for our specific case, but maybe the information can help the BlazeDS team find the root cause making it incompatible with Coherence*Web.
Will give it a test run on our staging servers.

HttpSession retrieval with sessionId

I'm working with stateless EJB, passing in its methods objects included in
          HttpSession objects. Of course RMI serialization prevents me to update the
          objects in the HttpSession, but their copies.
          To achieve this, could I pass sessionId, and from the EJB retrieve the
          original HttpSession object?
          I see the HttpSessionContext interface has the method getSession(sessionId),
          but it's deprecated. Is there anything similar?
          Any help would be appreciated


HttpSession session = request.getSession(false);
log("SESSIONID> " + session.getId());
log("CREATIONTIME> " + session.getCreationTime());
log("ISNEW> " + session.isNew());
When I use this bit of code, I'm getting a NullPointerException on the methods for the session object.
The getSession(false) always returns null. Even with this piece of code, I'm
receiving different sessionID's for the same session.
     HttpSession session = request.getSession(false);
     if (session == null) {
          session = request.getSession(true);
     log("SESSIONID> " + session.getId());
     log("CREATIONTIME> " + session.getCreationTime());
     log("ISNEW> " + session.isNew());
Extract of log file :
[24/12/2004 14:59:01:086 CET] BeatAndSoundServlet: SESSIONID> xtuzav6361
[24/12/2004 14:59:01:086 CET] BeatAndSoundServlet: CREATIONTIME> 1103896741086
[24/12/2004 14:59:01:086 CET] BeatAndSoundServlet: ISNEW> true
[24/12/2004 14:59:01:096 CET] BeatAndSoundServlet: -> showPlanning
[24/12/2004 14:59:07:094 CET] BeatAndSoundServlet: -> showAll
[24/12/2004 14:59:07:094 CET] BeatAndSoundServlet: SESSIONID> ioilxw6391
[24/12/2004 14:59:07:094 CET] BeatAndSoundServlet: CREATIONTIME> 1103896747094
[24/12/2004 14:59:07:094 CET] BeatAndSoundServlet: ISNEW> true
[24/12/2004 14:59:07:094 CET] BeatAndSoundServlet: -> showPlanning
[24/12/2004 14:59:25:251 CET] BeatAndSoundServlet: -> showAll
[24/12/2004 14:59:25:251 CET] BeatAndSoundServlet: SESSIONID> 9vknmj63i1
[24/12/2004 14:59:25:251 CET] BeatAndSoundServlet: CREATIONTIME> 1103896765251
[24/12/2004 14:59:25:251 CET] BeatAndSoundServlet: ISNEW> true
[24/12/2004 14:59:25:251 CET] BeatAndSoundServlet: -> showPlanning
My browser is enabled for cookies. The entry 'session.useCookies=true' exists in the zone.properties file. Strange...
Tom

HttpSession replication and server state saving

The UIComponent class is not serializable, certainly because it is the StateManager which is responsible of saving its state.
But the default server state manager of the RI stores the whole component tree in the HttpSession. That means that it won't work in clustered environments where the session has to be serialized for replication between servers.
Will this be addressed in the final release ?

E> This seems like a really BIG hole that Sun should fill very quickly!
Thanks for your input. Note: spec is intentionally very vague about the
specifics of state saving, except to say that the implementation must
support two options: client and server. Therefore, any solution
implemented in the Sun RI will likely be specific to that RI. Perhaps
we can consider standardizing the approach to clustering in a future
version of the spec.
E> I came across this thread because I am testing the viability of using
E> JSF in a JBoss clustered environment (and began getting serialization
E> errors when I add the <distributable/> stanza to my web.xml file). I
E> am probably not alone in my discomfort at having to replace a core
E> JSF class with a "patch" just to get session replication to work. Why
E> can't you or someone at Sun provide the resolution? All, that aside
E> you a JSF expert at least provide detailed specifics as to how the
E> proposed fix can be implemented by corporate JSF developers?
Here's one very important aspect of application architecture that I'm
surprised hasn't been pointed out before. Your application should be
designed such that the all user state resides OUTSIDE of the JSF
realm, and can therefore be made highly available by virtue of being
stored in something that does support HA. JSF UI state should mostly be
in request scope anyway. This is why we spent so much time on the
ValueBinding API.
E> Hope to see you at JavaOne (with more questions of
E> course)!
Yes, the entire Sun RI team, and several key EG members will be
available at BOF-2220
<http://www.javaone04.com/catalog/catalog/sessionDetail.jsp?hd=true&SESSION_ID=10589&form=searchform>.
Tuesday 29 June 2004 7:30 pm.
Ed (EG Member)

All session objects should be serializable to replicate error.

Hi All,
Having 'EmployeeBean' and it is having below properties with getters and setters methods
private long emp_id;
private String emp_name;
private java.sql.Timestamp date_of_join;
private boolean isActive;
private int dept_no;
Adding multiple employees(creating multiple EmployeeBean) into an ArrayList and storing this ArrayList into a Session object. This is working fine but when I move this code to production(cluster environment) it is throwing below error
<Aug 23, 2011 2:15:40 PM EDT> <Error> <Cluster> <BEA-000126> <All session objects should be serializable to replicate. Check the objects in your session. Failed to replicate non-serializable object.
java.rmi.MarshalException: failed to marshal update(Lweblogic.cluster.replication.ROID;ILjava.io.Serializable;Ljava.lang.Object;); nested exception is:
 java.io.NotSerializableException: my.company.beans.EmployeeBean
 at weblogic.rjvm.BasicOutboundRequest.marshalArgs(BasicOutboundRequest.java:90)
 at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:221)
 at weblogic.cluster.replication.ReplicationManager_1032_WLStub.update(Unknown Source)
 at sun.reflect.GeneratedMethodAccessor163.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 Truncated. see log file for complete stacktrace
Caused By: java.io.NotSerializableException: my.company.beans.EmployeeBean
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
 at java.util.ArrayList.writeObject(ArrayList.java:570)
 at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 Truncated. see log file for complete stacktrace
Can someone please let me know, why I'm getting this error? The EmployeeBean should implement serializable? Is there any problems/cons to implement serializable?
Having other bean(LoginBean) and I'm keeping this bean into session and it doesn't implement serializable, not getting any error for this bean(LoginBean). Only difference is LoginBean is not added to ArrayList.
Why it is throwing error for EmployeeBean and not for LoginBean??
Thanks in advance.
Regards,
Sharath.

The EmployeeBean should implement serializable? - Yep Is there any problems/cons to implement serializable? - No
Just add java.io.Serializable to the EmployeeBean, for example,
public class EmployeeBean implements Serializable {
}For LoginBean you have probably, configured to be in the session, by using faces-config.xml.
In the case of EmployeeBean (or the object graph it is part of) have you used HttpSession.setAttribute(...)?
Note that setAtttibute(...) is the trigger for an application server to replicate the object.
In this case all objects in the object graph have to be serializable.
Typically, objects should be Serializable when they are part of the session and you are using a clustered environment.

Serialization of HttpSessions

Similar Messages

Maybe you are looking for