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