yes surely if you can put some effort to create a github project it can really help since we'll identify the issue really faster (and where it comes from ;))
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:32 GMT+01:00 Karl Kildén <[email protected]>: > 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
