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 <[email protected]>: > 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 < > [email protected]> > 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 <[email protected]>: > > > 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 > > > [email protected] > > > 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 +----------------------------------------------------------+
