Yes PostConstruct is called once. If you need request/client specific state I would use Stateful or CDI, I was only giving you some extra information about Stateless :). Anyway I am not pretty sure that it will be a good practice mix Stateless behaviour with Stateless EJB with stateful behaviour by using RequestScoped.
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 > > +----------------------------------------------------------+ > > > -- +----------------------------------------------------------+ Alex Soto Bueno - Computer Engineer www.lordofthejars.com +----------------------------------------------------------+
