Good point. Thanks for your input. On 4 Sep 2014 11:14, "Romain Manni-Bucau" <[email protected]> wrote:
> would be the same, @Lock don't forbid you to use @Lock(WRITE) later > but tha's up to you if you don't need it > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-09-04 10:55 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > > @Romain > > > > Or should I even do @Singleton @ConcurrencyManagement(BEAN) if I need no > > state? I know you said that the performance implications would be about > the > > same? > > > > > > On Thu, Sep 4, 2014 at 10:39 AM, Romain Manni-Bucau < > [email protected]> > > wrote: > > > >> hmm for webservices which are most of the time staeless I'd use > >> @Singleton @Lock(READ), do you need any state? > >> > >> > >> Romain Manni-Bucau > >> Twitter: @rmannibucau > >> Blog: http://rmannibucau.wordpress.com/ > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> Github: https://github.com/rmannibucau > >> > >> > >> 2014-09-04 10:30 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > >> > @Alex and @Romain > >> > > >> > Thanks for your answers. I forgot to mention that we need (for most of > >> the > >> > cases) transactions. > >> > > >> > For some of the production environments we use WebSphere 8.5.5 which > >> still > >> > is JavaEE 6 so we need to use EJB to handle transactions. > >> > > >> > @Romain > >> > > >> > I agree with your thoughts, the requirements from case to case should > >> > decide the inplementation. I just thought listing pros and cons was a > >> good > >> > way to sort of wrap our heads around what might be things to > consider. We > >> > expose services using JAX-WS and/or JAX-RS and we need transactions. > >> > Considering that I understand that you rather would use @Stateful > >> > @RequestScoped rather than @Stateless? > >> > > >> > @Alex > >> > > >> > I see your comment on the fact that multiple requests each will use > its > >> own > >> > instance of a stateless EJB. i assume however that @PostConstruct will > >> only > >> > be called once when the container instantiate the EJB and put it in > the > >> > pool and not once per request. So if I need request/client specific > state > >> > setup in @PostConstruct I would need to use a @Stateless > @RequestScoped > >> EJB > >> > instead. Was your comment about that? > >> > > >> > Thanks > >> > On 4 Sep 2014 09:22, "Alex Soto" <[email protected]> wrote: > >> > > >> >> BTW in Java EE 7 with @Transactional then you can create a POJO with > >> >> RequestScoped and Transactional so no EJB is required. > >> >> > >> >> Moreover keep in mind that an stateless bean is used during the whole > >> >> request, two concurrent requests won't reuse the same stateless bean. > >> >> Alex. > >> >> > >> >> > >> >> 2014-09-04 9:17 GMT+02:00 Romain Manni-Bucau <[email protected] > >: > >> >> > >> >> > Hi > >> >> > > >> >> > interesting analyzis and way of doing it :). Personally I think the > >> >> > other way around actually: > >> >> > > >> >> > 1) what do I need? > >> >> > [potential answer] storing my state during JSF request -> I add > >> >> > @RequestScoped > >> >> > > >> >> > 2) oops, I need transactions > >> >> > -> add @Stateful (or use a service to delegate depending the case > and > >> >> > code architecture) > >> >> > > >> >> > etc... > >> >> > > >> >> > > >> >> > What you forgot in pro/cons is stateless are pooled so they can be > a > >> >> > bottleneck if not well configured > >> >> > > >> >> > > >> >> > Generally I don't use stateless anymore, only @Singleton for EJBs > and > >> >> > @Stateful if really a CDI bean doesn't match my case - for JSF you > >> >> > often needs it to store a state within a scope (request, session, > view > >> >> > typically) and flush it at the end of the action in a transaction. > >> >> > > >> >> > So to come back to your question: start with the minimum you need > and > >> >> > don't try to get a "always use XXX", it would just be broken as all > >> >> > general rules ;). Passing from an EJB to a CDI bean is almost > nothing > >> >> > to do and the only relevant info is a benchmark on *your* app (I > saw > >> >> > cases where postconstruct can be considered as free and cases where > >> >> > injections were costly, so it depends too much on the code you > >> >> > evaluate to be general. > >> >> > > >> >> > Hope it helps even if adding some blur ;) > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > Romain Manni-Bucau > >> >> > Twitter: @rmannibucau > >> >> > Blog: http://rmannibucau.wordpress.com/ > >> >> > LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> >> > Github: https://github.com/rmannibucau > >> >> > > >> >> > > >> >> > 2014-09-04 8:48 GMT+02:00 Lars-Fredrik Smedberg < > [email protected]>: > >> >> > > Hi > >> >> > > > >> >> > > Trying to sort out the pros and cons of using a @Stateless EJB > vs a > >> >> > > @Stateful @RequestScoped EJB, can someone help me with the > following > >> >> > claims > >> >> > > and see if I missed out on something?? > >> >> > > > >> >> > > Possible pros of @Stateless EJB > >> >> > > > >> >> > > - Any expensive @PostConstruct methods will be run once when the > >> EJB is > >> >> > > instantiated and put in the pool and not per request > >> >> > > - Control over concurrency/resources on the server by being able > to > >> >> > > configure the EJB pools > >> >> > > - Reuse of EJBs will not create much garbage to be handled by > the GC > >> >> > > > >> >> > > Possible cons of @Stateless EJB > >> >> > > > >> >> > > - Having to tune and follow up on the pool usage. This might be > >> >> > troublesome > >> >> > > depending on the organization and responsibilities > >> >> > > - Depending on the tuning requests might need to wait for an > >> instance > >> >> to > >> >> > be > >> >> > > available in the pool > >> >> > > - @PostConstruct can not initialize any request/user dependent > >> state of > >> >> > the > >> >> > > EJB since it will be shared by others > >> >> > > > >> >> > > Possible pros of @Stateful @RequestScoped EJB > >> >> > > > >> >> > > - No configuration of EJB pools needed > >> >> > > - No calls will have to wait for an available instance, as many > >> >> instances > >> >> > > as needed will be created > >> >> > > - @PostConstruct can be used to initialize request/user dependent > >> state > >> >> > of > >> >> > > the EJB, the EJB instance will not be reused > >> >> > > > >> >> > > Possible cons of @Stateful @RequestScoped EJB > >> >> > > > >> >> > > - An expensive @PostConstruct will affect performance since it > will > >> run > >> >> > > once per request (client request) > >> >> > > - Generates more garbage to be handled by the GC > >> >> > > - No built in way to control the number of concurrent calls > >> >> > > > >> >> > > > >> >> > > - Are there any other obvious pros and cons with the two ways > above? > >> >> > > - In the end will it all depend on the use-case and how many pros > >> the > >> >> > > use-case/scenario will make use of? > >> >> > > - Letting CDI lifecycle create and destroy stateful EJBs per > request > >> >> > > compared to handling a pool of stateless EJBs, is there a big > >> >> performance > >> >> > > difference? > >> >> > > > >> >> > > > >> >> > > Hoping for help to shed some light on this > >> >> > > > >> >> > > Regards > >> >> > > Lars-Fredrik > >> >> > > > >> >> > > > >> >> > > -- > >> >> > > Med vänlig hälsning / Best regards > >> >> > > > >> >> > > Lars-Fredrik Smedberg > >> >> > > > >> >> > > STATEMENT OF CONFIDENTIALITY: > >> >> > > The information contained in this electronic message and any > >> >> > > attachments to this message are intended for the exclusive use of > >> the > >> >> > > address(es) and may contain confidential or privileged > information. > >> If > >> >> > > you are not the intended recipient, please notify Lars-Fredrik > >> Smedberg > >> >> > > immediately at [email protected], and destroy all copies of > this > >> >> > > message and any attachments. > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> +----------------------------------------------------------+ > >> >> Alex Soto Bueno - Computer Engineer > >> >> www.lordofthejars.com > >> >> +----------------------------------------------------------+ > >> >> > >> > > > > > > > > -- > > Med vänlig hälsning / Best regards > > > > Lars-Fredrik Smedberg > > > > STATEMENT OF CONFIDENTIALITY: > > The information contained in this electronic message and any > > attachments to this message are intended for the exclusive use of the > > address(es) and may contain confidential or privileged information. If > > you are not the intended recipient, please notify Lars-Fredrik Smedberg > > immediately at [email protected], and destroy all copies of this > > message and any attachments. >
