tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Date Thu, 04 Sep 2014 08:39:57 GMT
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 <itsmeden@gmail.com>:
> @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" <asotobu@gmail.com> 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 <rmannibucau@gmail.com>:
>>
>> > 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 <itsmeden@gmail.com>:
>> > > 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 itsmeden@gmail.com, and destroy all copies of this
>> > > message and any attachments.
>> >
>>
>>
>>
>> --
>> +----------------------------------------------------------+
>>   Alex Soto Bueno - Computer Engineer
>>   www.lordofthejars.com
>> +----------------------------------------------------------+
>>

Mime
View raw message