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 +----------------------------------------------------------+
