On Jun 17, 2015, at 11:37 AM, Matej <[email protected]> wrote: > 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.
Excellent usage. Extremely refreshing to hear of someone using the pooling aspect consciously and effectively! -David > 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> >>>> >>> >>> >>
