Removing the object from the session only means that object is available for garbage collection. It does not guarantee though that it will be garbage collected immediately when garbage collection process takes place. It depends on how your JVM(I think it depends per application server, for example, BEA has its proprietary implementation of JVM called JRockit) implemented or used the particular garbage collection algorithm. Hence, this explains why the recently removed object from session is not garbage collected yet.
Per with half of objects are still in Web and EJB tier, what kind of EJB did you call, it is a stateless or staful session bean? or it is a entity bean that is passed back to web?
Partha Ranjan Das <partharanjan.d@SONATA-SOFTWARE.COM> wrote:
Hi J2EE Gurus,
We are having a seemingly peculiar problem.
In this case an activeX client makes multiple HTTP calls to a servelt in a web server serially. The servlet has a single method to handle all these HTTP calls (called "FP calls") . This method has many switch-case statements for these FP calls. In the first "case" statement, it calls the EJB tier and gets a collection of serializeable Value Object (Or Data Transfer Objects) and this collection is maintained in the HttpSession by using HttpSession.setAttribute("XYZ",object). Now, when the following call, made by the same ActiveX client, (in this FP series of calls) comes for the next FP call, it uses the collection stored in session. The last FP call, after doing business operations, does HttpSession.removeAttribute("XYZ"). So at this point, we assume that this collection, which was so far bound to key "XY
Z",
should be ready for garbage collection....right?
Wrong. When we ran JProfiler to find what all objects are there in the memory at this point (after calling GC manually using the profiler),--- we find that those objects, constituting that collection, which is supposed to be garbage collected, are not at all garbage collected. What is more ashtonishing is that we find half of these objects are lying in the EJB tier and half in the web tier. But the servlet responds to all the FP calls and the ActiveX displays all the information required. This means that the HTTP responses for all the HTTP "FP call" requests have been duely and fully made.
Does anybody have any idea why, after calling session.removeAttribute also, these objects are not garbage collected and also why half of these objects are still lying in the EJB tier, even after EJB method has ended and GC is called using the profiler? We are not maintaining this collection as a static propoerty of any of the classes,
either
in web or EJB tier. We are using WSAD 5.1.
Thanks in advance,
Regards,
Partha
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".