As a pure user feedback, we've been using OpenEJB/TomEE stateless beans on huge applications and it does not produce any significant nor noticeable overhead as soon as the pool size is well set up.
So i'm really confident. That said, the way singleton works with a READ lock is better in lots of cases (no instances to manage, no locks in the pool, less memory consumption, etc). But you are also right, it does not apply in any cases, I mean using stateless session beans is still relevant in some situations. Even if I tend to preferably use Singleton, it's sometimes not applicable. Moreover you are right, EM is not thread safe as per the spec even if some implementations (Hibernate for example) are in some situations. We discussed that point recently in the expert group as far as I recall. Hope it helps, Jean-Louis 2013/3/13 zeeman <[email protected]> > I have to disagree with some of the gurus here. In most cases a stateless > or > singleton bean is going to use an entityManager/hibernate session to get > data to/from the DB. EM is not thread safe, using a singleton with read > lock > will cause concurrency issues on EM. So stateless in that case is the way > to > go as it'll have its own EM instance. For scalable applications this would > work well. > > Having strict pooling = false with proper max/min values (based on expected > app load) will work as suggested. > > > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html > Sent from the OpenEJB User mailing list archive at Nabble.com. > -- Jean-Louis
