Romain you are right I am to tired now... Maybe I am quite stupid for putting @RequestScoped on it since that is how I used to do it when I did tomcat. It should not even do anything when I think about it.
This problem seems very related to how I use @Async. Maybe I should move my topic with a new mail to tomee list? On 2 March 2015 at 19:27, Romain Manni-Bucau <[email protected]> wrote: > well > > deltaspike data doesn't want @RequestScoped, it just used the contextual > entity manager - this comes from what JSF guys do AFAIK. > > Wonder if you could reproduce it with OpenJPA or if it is due to the fact > eclipselink is storing itself a state somewhere. Any idea? > > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-03-02 19:13 GMT+01:00 Karl Kildén <[email protected]>: > >> Romain, >> >> Deltaspike Data wants a @RequestScoped entityManager. If I want to use >> Data module from my batches, how to combine that? >> >> Also, this whole problem seems linked to @Async not batch (I thought >> batch was implemented with @Async) >> >> On 2 March 2015 at 18:50, Romain Manni-Bucau <[email protected]> >> wrote: >> >>> batchee default impl shouldnt be @Async excepted if you imported the >>> module Mark added for WAS - but your thread naming is closer to tomee ;). >>> >>> batches are by design asynchronous so no need of @Async to launch them. >>> >>> then all depends your @requestScoped. if it matches nothing the >>> container handles (http request or synchronous ejb call) then you should >>> handle it yourself but sounds like a workaround more than a fix which would >>> be using a correct scope. >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>> <http://www.tomitribe.com> >>> >>> 2015-03-02 18:44 GMT+01:00 Karl Kildén <[email protected]>: >>> >>>> 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 >>>> requestscoped... >>>> >>>> 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; >>>> >>>> @Produces >>>> @RequestScoped >>>> 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 <[email protected]> >>>> 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 <https://twitter.com/rmannibucau> | Blog >>>>> <http://rmannibucau.wordpress.com> | Github >>>>> <https://github.com/rmannibucau> | LinkedIn >>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>>>> <http://www.tomitribe.com> >>>>> >>>>> 2015-03-02 18:10 GMT+01:00 Karl Kildén <[email protected]>: >>>>> >>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>> >> >
