David. I just wanted to add, as probably our email started this thread. We used statelesses instead of singletions(read) because this allowed us to somehow "tune" how many requests you let to the DB.
And cause, we had some issue, that the system somehow deadlocks, cause Hibernate uses multiple connections per session, we used the Stateless pool size parameter for tuning how many requests to process. Otherwise this is shifted form the Stateless to the JDBC pool. BR Matej 2015-06-15 10:48 GMT+02:00 David Blevins <[email protected]>: > Side note to readers: best use @Singleton with @Lock(READ) for stateless > applications unless there is some specific need to keep a finite pool of > instances and lock threads till an instance becomes available. > > On Mon, Jun 15, 2015 at 9:46 AM, David Blevins <[email protected]> > wrote: > > > The trick is we need to rely on shutdown() being called when the bean is > > undeployed to ensure the application can successfully terminate and not > > leak timers. > > > > Sharing a ScheduledExecutorService per application is the best we could > do > > in that regard. The shutdown logic would still become a bit difficult as > > would the Stateless container logic. The StatelessInstanceManager which > > builds the pool would also have to build the ScheduledExecutorService and > > pass it in, track the ScheduledExecutorService in the ApplicationContext > or > > ModuleContext and clean it up on undeploy. The StatelessInstanceManager > > would have to be careful not to create the ScheduledExecutorService more > > than once per app or destroy it more than once per app. > > > > The pool class would need to remain generic (not specific to stateless > > beans) and still be prepared to construct a ScheduledExecutorService if > one > > wasn't passed in. Similar to what it does now for the regular Executor > > service. > > > > > > -David > > > > > > On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau < > [email protected] > > > wrote: > > > >> Hi guys, > >> > >> already got this issue and Mark pinged me about it yesterday. ATM we > have > >> 1 > >> eviction thread by stateless instance manager (pool). So if you have 100 > >> stateless beans you then have 100 threads doing nothing. > >> > >> Do we want to reduce it to N fixed threads (default to 3 maybe?) per > >> stateless container (but multiple tasks to keep access timeout and close > >> timeout respected)? > >> > >> Romain Manni-Bucau > >> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >> <http://rmannibucau.wordpress.com> | Github < > >> https://github.com/rmannibucau> | > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > >> <http://www.tomitribe.com> > >> > > > > >
