Detach on cascade turns on phatonmly

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Detach on cascade turns on phatonmly

pveselov
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
Reply | Threaded
Open this post in threaded view
|

Re: Detach on cascade turns on phatonmly

Mark Struberg-3
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 <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Detach on cascade turns on phatonmly

pveselov
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 <[hidden email]>
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 <[hidden email]>:
> >
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: Detach on cascade turns on phatonmly

Mark Struberg-3
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 <[hidden email]>:
>
> 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 <[hidden email]>
> 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 <[hidden email]>:
>>>
>>> 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