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