Garbage collection with CMP Entity beans

[sudheshna Iyer]

I need to understand how the garbage collection works with CMP entity beans. We are using bea weblogic 8.1SP3.

What are the steps that the developer has to take inorder to avoid the memory leaks with CMP entity beans?

Thank you.

[Ulf Dittmer]

Why would you think that GC works differently with CMP than in other Java code? One would hope that the EJB server doesn't keep references to unused objects around (which would prevent GC), just like the rest of the application shouldn't keep those references around.

[sudheshna Iyer]

I have an application which has a bean that is used by jsp(useBean class= javabean)
This bean has Map(Collection of DTOs) as a instace variable. These DTOs are loaded with the data from the session bean
which intern gets data from CMP entity beans.

How do I make sure that this bean is garbage collected? Since this bean has large number of DTOs stored in MAP,
how do I release these resources(esp Map) inorder to make sure that there is no memory leak?

I am asking this question because we are having outofMemoryError when the application is deployed and we are
investigating what caused the problem.

[Ulf Dittmer]

It would depend on what lifespan the bean has. If it is session or applications (as opposed to page or request), it could conceivable live for a long time.
Once you know that you're done with your map -but the map object actually lives on- you should set the reference to null, and possibly null out the map as well. This might help, but then, it might not. Probably best to do some memory profiling.

[sudheshna Iyer]

The scope of the bean is request:
<jsp:useBean id="xx" class="beans.xxBean" type="beans.xxBean" scope="request" />
This is the bean(xxBean) that has Map with collection of DTOs. Since this bean has request scope, I am assuming that the Bean will get garbage collected after the
request and hence nullifying all the instance variables it has and hence releasing all the EJBs. Is this correct?
Initially to start with, I am seeing memory consumption as 300MB(from weblogic console monitoring) and when I deployed and try accessing this site, memory consumption went up to 450MB. But the memory is not coming back to 300MB and it is staying at 425MB or so even after waiting for a long time after the request(more than 20min).
I want the resources to be released. Won't the resources be released for the request scope by itself or do we need to do any extra steps?

[Valentin Tanase]

Hi sudheshna,

Initially to start with, I am seeing memory consumption as 300MB(from weblogic console monitoring) and when I deployed and try accessing this site, memory consumption went up to 450MB. But the memory is not coming back to 300MB and it is staying at 425MB or so even after waiting for a long time after the request(more than 20min).

You can use the console and force a garbage collection and see what happens. If the memory won�t get released, then I believe you should refactor little bit your code in order to overcome this problem. Now let me tell you a short story about the way garbage collectors work:
Most of the modern GCs uses object reference transversal in order to figure out which are all reachable objects and the GC will mark these objects. The next thing the GC does is to scan the heap removing the non-reachable objects. This is commonly referred as sweeping. The problem with this approach is that the memory can fragment over time to the point where there are a lot of small useless memory segments. Hence many GCs w ill rearrange the objects in memory to compact the live object and make the memory continuous.
My point is that the GC removes only the �orphan� objects. In your case if your SLSB keeps a list of DTOs, then the GC will remove the list if those DTOs becoming orphans. This will happen for example if the �parent�, which is the bean instance will get garbage collected. But as you know with SLSBs, they are instance pooled and therefore they don�t get garbage collected; the container will keep them in the pool for as long as the application exists or the server is shouting down. Moreover from what I know weblogic never shrinks the free pool and your bean instance will probably never get garbage collected.
In my opinion you have at least three solutions:

Create a business method in your bean that returns the map of DTOs rather than maintaining this list in your bean as an instance variable.

Programmatically loop through the list of DTOs and remove them from the list (setting the references to null).

Use soft references. This way the GC will garbage collect the DTOs as more memory is required, although they are not orphans. This of course might have other implications but is worth trying.

Regards.

[Tim Holloway]

You referred to Entity Beans - specifically CMP. Don't forget that one of the reasons for using EJBs over lighter-weight persistence object is that the container caches them.

You can play GC tricks all day long, but as long as the beans are in cache, they're still being referenced and GC can't free their memory.

So a good place to start looking is the cache management part of the WebLogic admin utility.

[Valentin Tanase]

Hi Tim,

You referred to Entity Beans - specifically CMP. Don't forget that one of the reasons for using EJBs over lighter-weight persistence object is that the container caches them.

As far as I understand the posting, other seems to be the issue here. The problem is not the CMP entity beans, but the Map of DTOs that the SLSB maintains as an instance variable (probably he used a memory profiling tool in order to conclude so and I�m not debating this).
Sudheshna can you please confirm whether my understanding is right or not?
However if my assumption is correct then all three points I made in the previous posting could be possible solutions to this issue.
Regards.

[sudheshna Iyer]

Here is the architechture:
jsp-->Java bean(has instance variable of Map)-->bean.init() --> calls Stateless bean SSLB -->access (CMP)EntityBeans
(CMP)EntityBeans -->gets Collection of DTOs(having one-to-many and many-to-many relationships -->returns to SSLB-->returns to java bean's
instance variable map -->gets used by jsp

This is the same application that I was discussing in thread-->"Delete cached data and load from database".

Create a business method in your bean that returns the map of DTOs rather than maintaining this list in your bean as an instance variable.

Isn't it a normal practice to maintain instance variables and get/setter methods to access the instance variables in jsp.

Programmatically loop through the list of DTOs and remove them from the list (setting the references to null).

When should I do this? There is no logout on the screen. This is a public site.

Use soft references. This way the GC will garbage collect the DTOs as more memory is required, although they are not orphans. This of course might have other implications but is worth trying.

Should I soft reference the map in the java bean? What are the other implications?

[Karthik Guru]

Hi Valentin,

As Tim pointed out could'nt it be the weblogic entity bean cache that is taking up the memory ? ( I mean say a finder that has resulted in huge number of beans getting loaded in the cache)..I assume that sudeshna would have employed optimistic caching by now

[sudheshna Iyer]

No, I still am using database concurrency. This is mainly because user wants to see the latest data from the database and no scheduling of cache replenishment is agreed upon!

[sudheshna Iyer]

No, I still am using database concurrency. This is mainly because user wants to see the latest data from the database and no scheduling of cache replenishment is agreed upon!

[Valentin Tanase]

Hi Sudheshna,

Isn't it a normal practice to maintain instance variables and
get/settermethods to access the instance variables in jsp.

Yes of course it is. But in your case this map could be the reason why you getting the OutOfMemoryExceptions. What I'm trying to say here is that you should redesign your app without maintaining the map within the SLSB. You should at least be able to build a new testing implementation very quick, testing and make sure whether this is the real problem or not.

When should I do this? There is no logout on the screen. This is a public site.

I would try first by simply implementing a public method on your bean that simply removes the DTOS from the map. Kind of cleanAll or something like this. Bottom line is that you need to make sure that the clients call this method after they displayed the data. A quick and dirty solution would be to make the jsp-bean to call the cleanAll after displaying the data. I agree is not the most exciting design solution but you can start from here, build a prototype, test it and you can improve it later if works.

Should I soft reference the map in the java bean? What are the other
implications?

You should soft reference every DTO in the map. If I remember correctly there is a WeekHashMap implementation of such a map. This is a great solution for caching data that could be garbage collected at any time. On the other hand the GC will collect the objects in order to release the memory (rather than raising the OutOfMemoryException). In a way it will do the cleanAll automatically, which is very nice. Unfortunately you cannot control this process and it could clean even DTOs that are currently displaying. It could happen that your jsp will try to display bunch of null records. Sure you can deal with the code, catching the NullPointerException and refreshing the page, but this coud be a pain in the �

Hi Karthik,

As Tim pointed out could'nt it be the weblogic entity bean cache that
Is taking up the memory ? ( I mean say a finder that has resulted in huge
number of beans getting loaded in the cache)..

Absolutely; but as I said at this time I'm starting from the premise that the problem is the map of DTOs. Sudheshna could build a basic prototype that deals with the map issue and testing it. If it works then end of story; otherwise we need to seek other solutions and this will definitely be a good starting point.
Regards.