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: Stateless EJB and attributes
Date Wed, 16 Jul 2014 11:23:14 GMT
so @PoolScoped ;)

actually I did it in my previous company using [pool] ;)


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-07-16 13:22 GMT+02:00 Alex Soto <asotobu@gmail.com>:
> Yes for this reason I said a pooled CDI because creation is a bit different
> in comparison to CDI.
>
>
> 2014-07-16 13:20 GMT+02:00 Romain Manni-Bucau <rmannibucau@gmail.com>:
>
>> Well stateless and requestscoped are different cause using N times a
>> request scoped bean you get a single instance where with stateless you
>> get potentially a new one each time (really depend the pool). If you
>> think to jsf it changes everything ;)
>>
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>> 2014-07-16 12:31 GMT+02:00 Jean-Louis Monteiro <jlmonteiro@tomitribe.com>:
>> > hum sounds acceptable
>> >
>> > I always use the JDBC connection pool when I need to explain.
>> > Because I can also say people that the pool is usually responsible for
>> > resetting the connections (autocommit for example) whereas the container
>> > does not do anything. This is under the bean provider responsibility.
>> >
>> >
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> >
>> > On Wed, Jul 16, 2014 at 12:22 PM, Alex Soto <asotobu@gmail.com> wrote:
>> >
>> >> So we can consider Stateless like pooled @RequestScope CDI bean. Of
>> course
>> >> with transactions, security, .... that comes with EJBs.
>> >>
>> >>
>> >> 2014-07-16 12:19 GMT+02:00 Jean-Louis Monteiro <
>> jlmonteiro@tomitribe.com>:
>> >>
>> >> > Stateless is definitely one of the worst name ever but that the
>> >> historical
>> >> > one.
>> >> > Stateless is per request as per the spec, which means that you can
>> hold a
>> >> > state if you want. The bean instance will never get shared between
>> >> > different threads at the same time (pool).
>> >> > But the bean provider is responsible for resetting the state before
>> >> ending
>> >> > the request so next thread can pick up the bean again in a relevant
>> >> state.
>> >> >
>> >> > --
>> >> > Jean-Louis Monteiro
>> >> > http://twitter.com/jlouismonteiro
>> >> > http://www.tomitribe.com
>> >> >
>> >> >
>> >> > On Wed, Jul 16, 2014 at 12:12 PM, Romain Manni-Bucau <
>> >> > rmannibucau@gmail.com>
>> >> > wrote:
>> >> >
>> >> > > I don't recall exactly our default but it is configurable/pluggable
>> >> > >
>> >> > >
>> >> > > Romain Manni-Bucau
>> >> > > Twitter: @rmannibucau
>> >> > > Blog: http://rmannibucau.wordpress.com/
>> >> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >> > > Github: https://github.com/rmannibucau
>> >> > >
>> >> > >
>> >> > > 2014-07-16 12:09 GMT+02:00 agumbrecht <agumbrecht@tomitribe.com>:
>> >> > > > Hi Alex,
>> >> > > >
>> >> > > > My understanding is that a request gets a checked out bean
>> instance
>> >> for
>> >> > > the
>> >> > > > duration of the method call. No other call will get this
bean
>> >> instance
>> >> > > until
>> >> > > > it is returned to the pool, after the method call completes.
>> >> > > >
>> >> > > > If you have a bean class field like private final AtomicInteger
>> then
>> >> > you
>> >> > > can
>> >> > > > increment it in every method call on that bean. You will
see that
>> >> each
>> >> > > bean
>> >> > > > will keep it's own call count. Putting it back into the pool
will
>> not
>> >> > > reset
>> >> > > > the variable.
>> >> > > >
>> >> > > > The chance that another call will get the same bean is never
>> >> > guaranteed.
>> >> > > > It's maybe interesting to see in a loop how often you actually
get
>> >> the
>> >> > > same
>> >> > > > instance.
>> >> > > >
>> >> > > > So a stateless bean can actually have state, but it 'may'
get
>> >> discarded
>> >> > > - At
>> >> > > > least when the instance is discarded. You may also get a
>> completely
>> >> new
>> >> > > > instance on the next call if the pool is starved etc.
>> >> > > >
>> >> > > > Anyway, putting anything into a class variable in a stateless
is
>> >> > probably
>> >> > > > not a good idea as the next caller may have access to it.
If you
>> do,
>> >> > > clean
>> >> > > > it up before returning from the call.
>> >> > > >
>> >> > > > Romain, without looking, do we pop from the head and put
back to
>> the
>> >> > > tail?
>> >> > > >
>> >> > > > Andy.
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > -----
>> >> > > >     --
>> >> > > >     Andy Gumbrecht
>> >> > > >
>> >> > > >     http://www.tomitribe.com
>> >> > > >     agumbrecht@tomitribe.com
>> >> > > >     https://twitter.com/AndyGeeDe
>> >> > > >
>> >> > > >     TomEE treibt Tomitribe ! | http://tomee.apache.org
>> >> > > > --
>> >> > > > View this message in context:
>> >> > >
>> >> >
>> >>
>> http://tomee-openejb.979440.n4.nabble.com/Stateless-EJB-and-attributes-tp4670426p4670477.html
>> >> > > > Sent from the TomEE Users mailing list archive at Nabble.com.
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> +----------------------------------------------------------+
>> >>   Alex Soto Bueno - Computer Engineer
>> >>   www.lordofthejars.com
>> >> +----------------------------------------------------------+
>> >>
>>
>
>
>
> --
> +----------------------------------------------------------+
>   Alex Soto Bueno - Computer Engineer
>   www.lordofthejars.com
> +----------------------------------------------------------+

Mime
View raw message