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 itsme...@gmail.com, and destroy all copies of this message and any attachments.
