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
