-
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 -
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. -
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 -
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. -
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. -
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. -
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