7 Replies Latest reply on Mar 26, 2004 2:41 AM by keesvandieren

possible memory leak in long lived transaction ?

grzegorzgłowaty Mar 19, 2004 8:03 AM

Hello.
Is there any way to implement a really long lived transaction in JBoss?
What I'm trying to implement is a big import involving creation of thousands
of entity beans (special bussiness logic is involved so it cannot be done by
simple database tables import). I can guarantee that I'm the only user of
Jboss working during this import so this transaction really doesn't need to
lock anything. It only should allow ATOMICITY so it will be rolled back
completelly if sth fails.
I'm using JBoss 3.2.3
On the default (Standard CMP) configuration I got "unable to passivate due
to ctx lock" after the cache becomes full. Eventually it leads to "out of
memory". It's obvious because Standard CMP uses pessimistic locking.

So I tried to execute it on "Instance per transaction" configuration with
NoLock and it no longer produces "unable to passivate" as it passivates
beans, but memory used still grows up, but slower (the question here is why
as the beans are passivated?) and finally I get "Out of memory exception".
There's no possibility of a memory leak on my code because if I do the above
in small transactions everything works fine.
So my question is: how to assure the atomicity of the big import operation
(as I mentioned I don't need any locking during the import as my import
transaction is the only one performing in the system).

Greetings,

greg

1. Re: possible memory leak in long lived transaction ?

scoy Mar 20, 2004 6:06 AM (in response to grzegorzgłowaty)

This is something that CMP is not particularly good at.

You would be better off using raw JDBC to perform this work and allow the database itself to manage the transaction.

We have run into this issue ourselves (with phone numbers for a carrier), and had to resort to this solution.

Steve
Actions
2. Re: possible memory leak in long lived transaction ?

grzegorzgłowaty Mar 20, 2004 1:45 PM (in response to grzegorzgłowaty)

Thanx for your reply scoy.
Here the problem is that a part of my logic is coded in the entity beans and i don't want to code it again when processing all through jdbc.
But my question is why they are still occupying the memory even if they got passivated. I'm not holding any lock on any of those beans.
Actions
3. Re: possible memory leak in long lived transaction ?

scoy Mar 21, 2004 10:42 PM (in response to grzegorzgłowaty)

I've always assumed that the memory is being consumed by the transaction manager.

I think that you will find that no actual database updates are performed until the the transaction is committed.

It might be possible to use XA Transactions to get the database to assume this overhead - I did not investigate this before because I only just thought of it.

Steve
Actions
4. Re: possible memory leak in long lived transaction ?

idxp Mar 22, 2004 2:59 AM (in response to grzegorzgłowaty)

Hi, All.

I think, the problem is caused not only by long transaction. Anything that lives long may cause problem since they occupy resources. For example, long-lived session beans & eneity beans will do even they are not involved in transactions.

Take my project as an example, there will be handerds of thousand entity beans, which will NEVER be removed once created. that is, every entity bean will live for ever. There will be one entity bean handling transactions. Each transaction is short. And I also encountered the "out of memory" problem.

What I am going to say it that, EJB model is not suitable for those projects, which are database centric, because that will make app server demand storage resources as much as DB server, something is a mirror.
Actions
5. Re: possible memory leak in long lived transaction ?

grzegorzgłowaty Mar 22, 2004 7:44 AM (in response to grzegorzgłowaty)

Here your problem is different. Probably it is caused by use of Hypersonic db as beans storage which (as you probably know) is normally configured to be in-memory db (so everything is stored in the memory). Try to switch to postgres or mysql and see if the problem persists.

My problem is completelly different.
Actions
6. Re: possible memory leak in long lived transaction ?

idxp Mar 26, 2004 12:40 AM (in response to grzegorzgłowaty)

Actually I am using MS Sql server and the DB is on another server.

"Grzegorz Głowaty" wrote:
Here your problem is different. Probably it is caused by use of Hypersonic db as beans storage which (as you probably know) is normally configured to be in-memory db (so everything is stored in the memory). Try to switch to postgres or mysql and see if the problem persists.

My problem is completelly different.
Actions
7. Re: possible memory leak in long lived transaction ?

keesvandieren Mar 26, 2004 2:41 AM (in response to grzegorzgłowaty)

You could try to use DAO objects: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Actions

Go to original post