batchee-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Kildén <>
Subject Re: TomEE mem leak using batchee with JTA transactions
Date Mon, 02 Mar 2015 17:44:16 GMT
I was wrong - this problem is in many other places not just batches!

regarding batch:

Interesting, I have not done anything (what I know) to enable

I thought Mark once told me that the impl in batchee for creating threads
is actually @Asynchronous. I also kind of recall not getting any extra
threads in my batchee jobs until I increased the @Async thread pool.

I do use @Async myself also here and there... In fact I think in one or two
cases Asynchronous will start the batch. I
use <class>org.apache.deltaspike.jpa.impl.transaction.EnvironmentAwareTransactionStrategy</class>

Then I use this producer:

@PersistenceContext(unitName = APP_NAME)
private EntityManager entityManager;

protected EntityManager createEntityManager() {
return this.entityManager;

And a normal stateless that uses either the entityManager or a repository
from deltaspike data (actually almost always the repository). This is the
only way I produce entityManagers.

Anyways my problem seems to be also in JSF @ViewScoped beans and whatnot.
Can it be that I must dispose my entitymanagers myself somehow?

On 2 March 2015 at 18:15, Romain Manni-Bucau <> wrote:

> Hmm
> for a batch this code doesnt mean anything - request scope. Did you hack
> something around detaspike to make it working?
> If this entity manager is used in an EJB this should be fine, if not then
> you need to ensure transaction are handled as you expect - should be the
> case with batchee but doesnt cost anything to validate it .
> Finally do you use @Asynchronous in your code otherwise you shouldn't see
> it
> Romain Manni-Bucau
> @rmannibucau <> |  Blog
> <> | Github
> <> | LinkedIn
> <> | Tomitriber
> <>
> 2015-03-02 18:10 GMT+01:00 Karl Kildén <>:
>> Hello,
>> I have some @Stateless that I use from batches. After the job has
>> finished I can see after a heap dump that the async thread seems to keep a
>> reference to the RepeatableWriteUnitOfWork. When I google I understand that
>> this is the EclipseLink entitymanager and since nobody seems to have called
>> clear on it my heap is getting pretty full...
>> I have defined my Batches with normal read process write. They are @Named
>> and simply inject my @Stateless. They @Stateless uses EntityManager and it
>> is produced like this:
>> @PersistenceContext(unitName = APP_NAME)
>> private EntityManager entityManager;
>> @Produces
>> @RequestScoped
>> protected EntityManager createEntityManager() {
>> return this.entityManager;
>> }
>> Not sure if I am missing some kind of disposal here?  I don't think so
>> because only the jobs get the UnitOfWork stuck on the heap.
>> Not sure I understand any of this very well. I can just clearly see that
>> my entire heap is now RepeatableWriteUnitOfWork tied to @ASynchronous
>> threads.
>> My memory dump could of course be sent to someone or shared desktop if
>> someone want's to help me understand this... Or maybe a pointer on where to
>> debug?
>> cheers

View raw message