You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Mark Struberg <st...@yahoo.de> on 2015/02/20 17:02:16 UTC
TransferFieldManager#fetchObjectField
Does anyone have a clue or remember why the TransferFieldManager#fetchObjectField sets the val to null after returning it?
The reason why I ask is that this currently creates an issue in the InverseManager for me.
In InverseManager#storeField line 332 this ‚destroys‘ the field sm as the val of it is null afterwards. And this subsequently creates an InvalidStateException in SingleFieldManager#preFlush line 567.
Does anyone remember something about that?
LieGrue,
strub
Re: TransferFieldManager#fetchObjectField
Posted by Rick Curtis <cu...@gmail.com>.
> But this could basically create the very same mem issues...
I haven't thought very long / hard about this one... but I struggle to come
up with a reason where this could/would cause some sort of a memory leak.
On Mon, Feb 23, 2015 at 2:13 PM, Mark Struberg <st...@yahoo.de> wrote:
> The fun thing is that fetchString doesn't set val = null.
> But this could basically create the very same mem issues...
>
> LieGrue,
> strub
>
> > Am 21.02.2015 um 15:47 schrieb Rick Curtis <cu...@gmail.com>:
> >
> >> I've checked the history of this very code and it seems to originate
> from
> > Kodo already... So I am a bit reluctant to touch it ;)
> > I noticed the same thing...
> >
> > On Fri, Feb 20, 2015 at 11:35 AM, Mark Struberg <st...@yahoo.de>
> wrote:
> >
> >> My current problem is that we try to use the InverseManager with
> >> action==Exception (so only check if the bidirectional relations are
> >> properly set in our code).
> >>
> >> The use case is the following
> >>
> >> Partner has a 1:n Customer
> >>
> >> p1.addCustomer(customer1).
> >>
> >> in a later request
> >>
> >> p1.removeCustomer(customer1);
> >>
> >> and add it to ANOTHER partner
> >> p2.addCustomer(customer1).
> >>
> >> The partnerId in customer1 gets properly updated.
> >>
> >> What happens is that the InverseManager invokes
> >> SingleFieldManager#fetchObjectField(fmd.getIndex()); to get the
> oldValue of
> >> the field (and does checks on it).
> >> And this fetchObjectField call actualle ERASES the internal val in the
> >> SingleFieldManager.
> >>
> >> This makes OpenJPA later blow up as this field is not nullable...
> >> I've checked the history of this very code and it seems to originate
> from
> >> Kodo already...
> >> So I am a bit reluctant to touch it ;)
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 20.02.2015 um 18:29 schrieb Rick Curtis <cu...@gmail.com>:
> >>>
> >>> I don't have an answer as to why we null the reference out. Can I get a
> >>> stacktrace for a bit of context?
> >>>
> >>> On Fri, Feb 20, 2015 at 10:02 AM, Mark Struberg <st...@yahoo.de>
> >> wrote:
> >>>
> >>>> Does anyone have a clue or remember why the
> >>>> TransferFieldManager#fetchObjectField sets the val to null after
> >> returning
> >>>> it?
> >>>>
> >>>>
> >>>> The reason why I ask is that this currently creates an issue in the
> >>>> InverseManager for me.
> >>>>
> >>>> In InverseManager#storeField line 332 this 'destroys' the field sm as
> >> the
> >>>> val of it is null afterwards. And this subsequently creates an
> >>>> InvalidStateException in SingleFieldManager#preFlush line 567.
> >>>>
> >>>>
> >>>> Does anyone remember something about that?
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> *Rick Curtis*
> >>
> >>
> >
> >
> > --
> > *Rick Curtis*
>
>
--
*Rick Curtis*
Re: TransferFieldManager#fetchObjectField
Posted by Mark Struberg <st...@yahoo.de>.
The fun thing is that fetchString doesn’t set val = null.
But this could basically create the very same mem issues…
LieGrue,
strub
> Am 21.02.2015 um 15:47 schrieb Rick Curtis <cu...@gmail.com>:
>
>> I've checked the history of this very code and it seems to originate from
> Kodo already... So I am a bit reluctant to touch it ;)
> I noticed the same thing...
>
> On Fri, Feb 20, 2015 at 11:35 AM, Mark Struberg <st...@yahoo.de> wrote:
>
>> My current problem is that we try to use the InverseManager with
>> action==Exception (so only check if the bidirectional relations are
>> properly set in our code).
>>
>> The use case is the following
>>
>> Partner has a 1:n Customer
>>
>> p1.addCustomer(customer1).
>>
>> in a later request
>>
>> p1.removeCustomer(customer1);
>>
>> and add it to ANOTHER partner
>> p2.addCustomer(customer1).
>>
>> The partnerId in customer1 gets properly updated.
>>
>> What happens is that the InverseManager invokes
>> SingleFieldManager#fetchObjectField(fmd.getIndex()); to get the oldValue of
>> the field (and does checks on it).
>> And this fetchObjectField call actualle ERASES the internal val in the
>> SingleFieldManager.
>>
>> This makes OpenJPA later blow up as this field is not nullable...
>> I've checked the history of this very code and it seems to originate from
>> Kodo already...
>> So I am a bit reluctant to touch it ;)
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 20.02.2015 um 18:29 schrieb Rick Curtis <cu...@gmail.com>:
>>>
>>> I don't have an answer as to why we null the reference out. Can I get a
>>> stacktrace for a bit of context?
>>>
>>> On Fri, Feb 20, 2015 at 10:02 AM, Mark Struberg <st...@yahoo.de>
>> wrote:
>>>
>>>> Does anyone have a clue or remember why the
>>>> TransferFieldManager#fetchObjectField sets the val to null after
>> returning
>>>> it?
>>>>
>>>>
>>>> The reason why I ask is that this currently creates an issue in the
>>>> InverseManager for me.
>>>>
>>>> In InverseManager#storeField line 332 this 'destroys' the field sm as
>> the
>>>> val of it is null afterwards. And this subsequently creates an
>>>> InvalidStateException in SingleFieldManager#preFlush line 567.
>>>>
>>>>
>>>> Does anyone remember something about that?
>>>>
>>>> LieGrue,
>>>> strub
>>>
>>>
>>>
>>>
>>> --
>>> *Rick Curtis*
>>
>>
>
>
> --
> *Rick Curtis*
Re: TransferFieldManager#fetchObjectField
Posted by Rick Curtis <cu...@gmail.com>.
> I've checked the history of this very code and it seems to originate from
Kodo already... So I am a bit reluctant to touch it ;)
I noticed the same thing...
On Fri, Feb 20, 2015 at 11:35 AM, Mark Struberg <st...@yahoo.de> wrote:
> My current problem is that we try to use the InverseManager with
> action==Exception (so only check if the bidirectional relations are
> properly set in our code).
>
> The use case is the following
>
> Partner has a 1:n Customer
>
> p1.addCustomer(customer1).
>
> in a later request
>
> p1.removeCustomer(customer1);
>
> and add it to ANOTHER partner
> p2.addCustomer(customer1).
>
> The partnerId in customer1 gets properly updated.
>
> What happens is that the InverseManager invokes
> SingleFieldManager#fetchObjectField(fmd.getIndex()); to get the oldValue of
> the field (and does checks on it).
> And this fetchObjectField call actualle ERASES the internal val in the
> SingleFieldManager.
>
> This makes OpenJPA later blow up as this field is not nullable...
> I've checked the history of this very code and it seems to originate from
> Kodo already...
> So I am a bit reluctant to touch it ;)
>
> LieGrue,
> strub
>
>
> > Am 20.02.2015 um 18:29 schrieb Rick Curtis <cu...@gmail.com>:
> >
> > I don't have an answer as to why we null the reference out. Can I get a
> > stacktrace for a bit of context?
> >
> > On Fri, Feb 20, 2015 at 10:02 AM, Mark Struberg <st...@yahoo.de>
> wrote:
> >
> >> Does anyone have a clue or remember why the
> >> TransferFieldManager#fetchObjectField sets the val to null after
> returning
> >> it?
> >>
> >>
> >> The reason why I ask is that this currently creates an issue in the
> >> InverseManager for me.
> >>
> >> In InverseManager#storeField line 332 this 'destroys' the field sm as
> the
> >> val of it is null afterwards. And this subsequently creates an
> >> InvalidStateException in SingleFieldManager#preFlush line 567.
> >>
> >>
> >> Does anyone remember something about that?
> >>
> >> LieGrue,
> >> strub
> >
> >
> >
> >
> > --
> > *Rick Curtis*
>
>
--
*Rick Curtis*
Re: TransferFieldManager#fetchObjectField
Posted by Mark Struberg <st...@yahoo.de>.
My current problem is that we try to use the InverseManager with action==Exception (so only check if the bidirectional relations are properly set in our code).
The use case is the following
Partner has a 1:n Customer
p1.addCustomer(customer1).
in a later request
p1.removeCustomer(customer1);
and add it to ANOTHER partner
p2.addCustomer(customer1).
The partnerId in customer1 gets properly updated.
What happens is that the InverseManager invokes SingleFieldManager#fetchObjectField(fmd.getIndex()); to get the oldValue of the field (and does checks on it).
And this fetchObjectField call actualle ERASES the internal val in the SingleFieldManager.
This makes OpenJPA later blow up as this field is not nullable…
I’ve checked the history of this very code and it seems to originate from Kodo already…
So I am a bit reluctant to touch it ;)
LieGrue,
strub
> Am 20.02.2015 um 18:29 schrieb Rick Curtis <cu...@gmail.com>:
>
> I don't have an answer as to why we null the reference out. Can I get a
> stacktrace for a bit of context?
>
> On Fri, Feb 20, 2015 at 10:02 AM, Mark Struberg <st...@yahoo.de> wrote:
>
>> Does anyone have a clue or remember why the
>> TransferFieldManager#fetchObjectField sets the val to null after returning
>> it?
>>
>>
>> The reason why I ask is that this currently creates an issue in the
>> InverseManager for me.
>>
>> In InverseManager#storeField line 332 this 'destroys' the field sm as the
>> val of it is null afterwards. And this subsequently creates an
>> InvalidStateException in SingleFieldManager#preFlush line 567.
>>
>>
>> Does anyone remember something about that?
>>
>> LieGrue,
>> strub
>
>
>
>
> --
> *Rick Curtis*
Re: TransferFieldManager#fetchObjectField
Posted by Rick Curtis <cu...@gmail.com>.
I don't have an answer as to why we null the reference out. Can I get a
stacktrace for a bit of context?
On Fri, Feb 20, 2015 at 10:02 AM, Mark Struberg <st...@yahoo.de> wrote:
> Does anyone have a clue or remember why the
> TransferFieldManager#fetchObjectField sets the val to null after returning
> it?
>
>
> The reason why I ask is that this currently creates an issue in the
> InverseManager for me.
>
> In InverseManager#storeField line 332 this 'destroys' the field sm as the
> val of it is null afterwards. And this subsequently creates an
> InvalidStateException in SingleFieldManager#preFlush line 567.
>
>
> Does anyone remember something about that?
>
> LieGrue,
> strub
--
*Rick Curtis*