> 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 <[email protected]> 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 <[email protected]>: > > > >> 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 <[email protected]> > 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 <[email protected]>: > >>> > >>> 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 <[email protected]> > >> 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*
