You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Lars-Fredrik Smedberg <it...@gmail.com> on 2014/09/04 08:48:08 UTC
Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
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.
Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Posted by Alex Soto <as...@gmail.com>.
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 <it...@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" <as...@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 <rm...@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 <it...@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
> > +----------------------------------------------------------+
> >
>
--
+----------------------------------------------------------+
Alex Soto Bueno - Computer Engineer
www.lordofthejars.com
+----------------------------------------------------------+
Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
Good point. Thanks for your input.
On 4 Sep 2014 11:14, "Romain Manni-Bucau" <rm...@gmail.com> wrote:
> would be the same, @Lock don't forbid you to use @Lock(WRITE) later
> but tha's up to you if you don't need it
>
>
> 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:55 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> > @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 <
> rmannibucau@gmail.com>
> > 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 <it...@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" <as...@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
> >> >> +----------------------------------------------------------+
> >> >>
> >>
> >
> >
> >
> > --
> > 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.
>
Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Posted by Romain Manni-Bucau <rm...@gmail.com>.
would be the same, @Lock don't forbid you to use @Lock(WRITE) later
but tha's up to you if you don't need it
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:55 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> @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 <rm...@gmail.com>
> 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 <it...@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" <as...@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 <rm...@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 <it...@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
>> >> +----------------------------------------------------------+
>> >>
>>
>
>
>
> --
> 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.
Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
@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 <rm...@gmail.com>
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 <it...@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" <as...@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 <rm...@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 <it...@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
> >> +----------------------------------------------------------+
> >>
>
--
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.
Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <it...@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" <as...@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 <rm...@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 <it...@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
>> +----------------------------------------------------------+
>>
Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Posted by Lars-Fredrik Smedberg <it...@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" <as...@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 <rm...@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 <it...@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
> +----------------------------------------------------------+
>
Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Posted by Alex Soto <as...@gmail.com>.
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 <rm...@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 <it...@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
+----------------------------------------------------------+
Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Posted by Romain Manni-Bucau <rm...@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 <it...@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.