batchee-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: TomEE mem leak using batchee with JTA transactions
Date Thu, 05 Mar 2015 18:38:47 GMT
> So why having @requestScoped in your backend // let close the troll here for that
Because transaction scoped EM doesn’t work quite often because JPA sucks when it comes to
lazy loading :)

LieGrue,
strub



> Am 05.03.2015 um 16:52 schrieb Romain Manni-Bucau <rmannibucau@gmail.com>:
> 
> 
> 2015-03-05 16:43 GMT+01:00 Mark Struberg <struberg@yahoo.de>:
> 
> > Am 05.03.2015 um 10:45 schrieb Romain Manni-Bucau <rmannibucau@gmail.com>:
> > Nothing technical, just real life. You tend to update the code to make it do what
you expect right? so if you use a bean in a front layer you can add front stuff inside and
then break your fully backend stuff.
> 
> Well in MY projects all the backend jars are simply not allowed to import any frontend
specs like servlet and JSF. We even have checkstyle rules to forbid the import of those ;)
> 
> 
> So why having @requestScoped in your backend // let close the troll here for that
>  
> 
> > The JBatch spec doesnt deal with scopes at all. CDI spec doesnt deal with jbatch.
Why CDI shouldnt be set up? Actually it is but not "web" scopes. As I said this choice is
to be aligned with other threading model in EE. No technical constraint, just trying to ensure
portability.
> 
> If the batch artifacts are CDI beans then CDI rules apply. As simple as that. This is
perfectly portable because of that.
> 
> 
> JBatch doesn't mention CDI at all...this is implementation specific: "An example of an
implementation-specific loader might be CDI or Spring DI."
>  
> LieGrue,
> strub
> 


Mime
View raw message