Ouch, I see what you mean. This is about the _default_ compat option. I gonna investigate - thanks!
LieGrue, strub > Am 22.07.2019 um 15:11 schrieb Pawel Veselov <pawel.vese...@gmail.com>: > > Hello Mark. > > I'm afraid you misunderstand the problem. Have you looked at the changes I > made? > There is no shared use for the entities between threads. We don't modify > the compat options directly, OpenJPA does that. > The problem is in OpenJPA changing compatibility variables (for cascading > operations), and that those variables are near global, > which causes other threads to behave differently and unexpectedly. Plus, > restoring the state has a race condition, causing > the wrong compat settings to get stuck. > > -- Pawel. > > > On Thu, Jul 18, 2019 at 9:30 AM Mark Struberg <strub...@yahoo.de.invalid> > wrote: > >> Hi Pawel! >> >> I fear you are hitting a rather lightly used path in OpenJPA. >> Although I wonder why you can hit a race condition? >> An EntityManager - and thus it's entities - are intended to be accessed >> only from a single thread at a time. >> Storing entities in a shared cache or whatever concurrently used object is >> always a bad idea. >> >> Can you probably shade a light on why you need those compat modes in the >> first place? >> Usually one doesn't need it if the app is properly designed. >> Are you probably working on an ancient legacy code. And in that case, what >> patterns do they use to work with JPA? >> >> txs and LieGrue, >> strub >> >> >>> Am 12.07.2019 um 15:37 schrieb Pawel Veselov <pawel.vese...@gmail.com>: >>> >>> Hello. >>> >>> https://issues.apache.org/jira/browse/OPENJPA-2792 >>> >>> Has took me a while to track down, and leaves quite unpleasant surprises, >>> as your entities become detached without warning, which leads to phantom >>> NPEs at places you never expect to happen. >>> >>> -- >>> With best of best regards >>> Pawel S. Veselov >> >> > > -- > With best of best regards > Pawel S. Veselov
