The point is that @RequestScoped per spec is available in all EJB invocations, all @PostConstruct CDI methods (which could be an @Named Batchlet, Reader, Writer, …), Message Driven Beans, JAX-RS and JAX-WS invocations, @Remote invocations, etc.
So despite it originates from ServletRequests it is really much more like a „@ThreadScoped“ actually. And that’s the reason why it is so tremendously popular. If I write something which is purely used in batches, then I’d also prefer @StepScoped. BUT if you need to reuse some Service which is e.g. also used in MDBs and Servlet invocations (JSF, etc) then @RequestScoped is the best you can do to store information which is not shared across different threads. LieGrue, strub > Am 04.03.2015 um 13:23 schrieb Romain Manni-Bucau <[email protected]>: > > @Mark: this has no link with EE 6 or 7, this is just a feature you want - > which is fine. JBatch doesn't deal with request scoped at all for instance. > That said for batches we have @JobScoped and @StepScoped which are still > exeprimental in batchee-cdi but can be more adapted. I know you are used to > it but I just find it a non-sense to have named request scoped something > which is not bound to any http request but that's another topic ;) > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-03-04 13:11 GMT+01:00 Mark Struberg <[email protected]>: > I did not read the full thread, but @Stateless and a @RequestScoped > EntityManager doesn’t make sense. > @Stateless basically _only_ works well with @PersistenceContext. If you use > DeltaSpike JPA then I’d rather use @AppliationScoped + @Transactional (from > deltaspike, not the half-broken one from EE7). > > > The EE support module btw is not just for WAS - it’s for all environments > which support EE but not yet EE7. The point is that with wrapping new thread > creating in @Asynchronous ejb call you get all the ThreadLocals set up for > free. And it’s even needed on some EE7 container as the concurrency-utils > spec doesn’t define that the Context for @RequestScoped needs to get started. > Some containers do it, others don’t… > > LieGrue, > strub > > > > > Am 02.03.2015 um 22:46 schrieb Romain Manni-Bucau <[email protected]>: > > > > Depend your conf for both but a thread stack will say you in 2s > > > > Le 2 mars 2015 22:35, <[email protected]> a écrit : > > Hrmm. Probably not. But maybe, I would expect a clear error message though? > > Maybe some other pool like stateless? Or will it get tired of waiting and > > throw? > > > > Skickat från min iPhone > > > > 2 mar 2015 kl. 21:58 skrev Romain Manni-Bucau <[email protected]>: > > > >> Full db connection pool? > >> > >> Le 2 mars 2015 21:04, "Karl Kildén" <[email protected]> a écrit : > >> Hi Romain, I removed all @Async usage and now it's the request thread that > >> hangs :D > >> > >> Actually when I dump the thread it seems to work forever being here and > >> there inside Eclipselink internals. Wonder if I triggered some kind of > >> endless loop. It looks like it because my heap is going way up and down > >> and I am the only one using the app and whatever task I started should be > >> done aaaages ago. > >> > >> Big help getting my attention away from batch and async :-) > >> > >> I will keep analyzing. If it's not local to my app I will try to reproduce > >> it in a sample (but it's always quite hard to do that :/) > >> > >> thanks again > >> > >> > >> > >> On 2 March 2015 at 20:07, Romain Manni-Bucau <[email protected]> wrote: > >> 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 | Blog | Github | LinkedIn | Tomitriber > >> > >> 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 | Blog | Github | LinkedIn | Tomitriber > >> > >> 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 | Blog | Github | LinkedIn | Tomitriber > >> > >> 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 | Blog | Github | LinkedIn | Tomitriber > >> > >> 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 > >> > >> > >> > >> > >> > >> > >> > >> > >
