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 <asot...@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 <rmannibu...@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 <jlmonte...@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 <asot...@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 < >> jlmonte...@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 < >> >> > rmannibu...@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 <agumbre...@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 >> >> > > > agumbre...@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 > +----------------------------------------------------------+
