Very true. Not having access to the actual code is very limiting. I took your suggestion and started looking in to the session tracking. My application uses the htpSession APIs. There is no URL rewriting taking place in my code.
The part of the application where I loose the session tracking is right after I performed a page assertion. What this means is that the client browser application runs a number of javascript to read through the contents displayed in their main browsing window. The information is serialized into a string, which is sent to the call center agent application. Once there, another set of javascripts takes the serialized string and builds up the corresponding web page including contents that the user view and have entered. The page is viewed using the cc agent cookie. In order foe the call center agent to view the exact same information, the client also sent the JSESSIONID for the client cookie. The code checks if the cookie needs to be applied, and if so, sets the current cc agent cookie = customer cookie. The page is then reloaded. I assume the that it is here that I loose the session. If the sessionID is kept in the cookie and the local cookie is set to the remote cookie, that mean the sessionID is changed. Hence, once the poller comes around, the poller GET is then associated with a different session (=new object instantiation). Is this reasoning correct? If this is the case, what is my workaround. The only thing I can think of is to delay the poller until the page assertion is completed and the old local cookie information is written back to the cookie. Other ideas... /Peter -----Original Message----- From: Hans Bergsten [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 12, 2002 2:04 PM To: [EMAIL PROTECTED] Subject: Re: Object garbage collected Peter Claesson (EUS) wrote: > I've continued to isolate and have found that the session Bean that I'm supposed > to have is somehow lost. I added a finalizer method to the bean class. What I see > throgh my debugging is that I get the session bean instantiated. After getting to my > "failure" point, I get another session bean instantiated. I shut down the application > propoerly, which to me indicates that the session is still valid. > I look at the debugging console (from servletexec) and see that the 2nd session bean >object > gets garbage collected. The 1st session bean obeject is never garbage collected. > What can cause such a behaviour? Shouldn't the bean object live until the session >expires? > > All JSP pages creates the bean as follows: > > <jsp:useBean id="csrCollabSession" scope="session" >class="com.upfront.htmlc.collab.CsrCollabSession"/> > [...] It's hard to tell what's wrong without really digging into the code for the whole application, but you obviously create the bean in the session scope. And like you suggest, the bean should therefore be available until the session terminates (by time-out or explictly invalidated) or is explicitly removed. The fact that it's in session scope means that there's at least one reference to it (from the data structure that implements the session collection), so it should not be GCed. Most likely your application loose track of the session ID at some point. For instance, if you use URL rewriting instead of cookie-based session tracking, a single link that is not rewritten means that the session ID is not passed to the server, so a new session is created. That's where I would start looking. Also, if you use servlets for some part of the application, make sure that the servlet and the JSP pages are always invoked with URLs containing the same context prefix (e.g. "/myapp/myServlet", "/myapp/mypage.jsp"). Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
