I agree Romain, but it only works in that specific situation: - EM type=TRANSACTION (not Extended) - Java EE environment (not Java SE)
And I also agree using a Singleton bean makes both true as it's not allowed as per the spec to obtain an Extended PC in a Singleton. My purpose was just to try to get things clearer. Jean-Louis 2013/3/13 Romain Manni-Bucau <[email protected]> > Em is clearly thread safe in a javaee envrt in transaction mode...at least > because of the transaction constraint you can get the same instance in > different threads > Le 13 mars 2013 08:40, "Jean-Louis MONTEIRO" <[email protected]> a écrit > : > > > 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 > > > -- Jean-Louis
