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