tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars-Fredrik Smedberg <itsme...@gmail.com>
Subject Re: Pros and cons using @Stateless EJB vs @Stateful @RequestScoped EJB
Date Thu, 04 Sep 2014 08:30:29 GMT
@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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message