Hi, In most cases it will be fine but a few ones can leak some attached entities or JDBC connection - even if unlikely. Also note that depending how your app is written and where it runs, your EMF can not be 1-1 with OpenJPA one so you can check there too.
That said rather than trying to clean up the EM in an illegal state (to reuse a java term ;)), maybe you should chase the bug in the application instead? Sounds like saner overall. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 6 oct. 2021 à 15:54, Tuomas Hynninen <tuomas.hynni...@surveypal.com.invalid> a écrit : > Hello, > > We have a web application where entity managers are bound to a thread for > the request duration and at the end of the request the entity manager is > closed and removed from the thread. > > When the entity manager is incorrectly shared between threads, and the > “Multiple concurrent threads attempted to access a single broker. By > default brokers are not thread safe; if you require and/or intend a broker > to be accessed by more than one thread, set the openjpa.Multithreaded > property to true to override the default behavior.” is thrown, we can’t > close the entity manager as it will throw the same exception. > > Is it safe to assume that the entity manager doesn’t need to be closed > when it’s in that state and it’s just enough to remove it from the thread? > Meaning that the EntityManagerFactory doesn’t pool or share entity managers > and it always creates a new one? > > OpenJPA version in use: 3.1.0. > > Thanks, > > -- > Tuomas Hynninen > Senior Software Engineer > Surveypal Oy > >
