Merging a detached instance with a new child in a unidirectional one-to-many association fails if the parent was previously loaded as a proxy

Description

Given a class One and a class Many with a unidirectional one-to-many relationship.

I'm getting a PropertyValueException: "not-null property references a null or transient value: test.Many._toManyBackref" when merging a detached "One" instance which contains a new "Many" instance if and only if the "One" was previously loaded as a proxy in the same transaction. The meat of the problem:

// create new One
One one = new One();
one.setOneOther(new One());
session.save(one);
commitAndGetNewSession();
/*

  • load saved instance as a proxy, but do not use it. we could use get() so we wouldn't get a proxy, but a real-world

  • application might have only loaded this instance transitively as a proxy before merging a detached instance, so this is a

  • real problem.
    */
    Object proxyWeDontUse = session.load(One.class, new Integer(one.getId()));
    assertTrue(proxyWeDontUse instanceof HibernateProxy);
    // use detached instance and add a Many
    one.getToMany().add(new Many());
    // merge the detached instance. this should work, but doesn't. the backref-getter doesn't correctly
    // find the parent object of the new Many, because the copyCache/mergeMap only contains the proxy loaded
    // above, but the entityEntries in PersistenceContext contain the raw unproxied object.
    session.merge(one);

In this simplified testcase I explicitly load the proxy. In our actual scenario, the One is loaded transitively as a child of yet another parent object - usually as a proxy. We need to load this to perform some authorization checks before we can actually merge the incoming detached One instance. This leads to the situation of having the proxy first and only then merging. As far as I understand the documentation, this should work.

I spent quite some time getting to the bottom of this - mostly debugging through the MergeEventListener. I found this: DefaultMergeEventListener uses Session.get() to load the persistent instance when merging a detached one. get() returns the proxy that was previously created. DefaultMergeEventListener then stores this returned proxy as the value of an entry in the copyCache. Later the backref-getter gets the actual persistent instance from the PersistenceContext and uses this to look for the detached instance in the mergeMap (which is the inverted copyCache, if I understood that correctly). But this only returns null, since the only key it can see is the proxy that was put as a value into the copyCache. Thus the backref-getter can't find its backref, leading to the exception.

Proposed solution: Store the persistent instance in the copyCache instead of the proxy, or do some dereferencing magic when looking for the backref. I can't judge that though - all I know about this right now comes from several hours of serious debugging.

I'm attaching an almost ready-to-use testcase as a zipped Eclipse project. Sources and config are in src/, the lib/ directory contains a hsqldb.jar which I used for fast testing. Simply add the required Hibernate jars and run the MergeUnidirectionalOneToManyTest. We currently use Hibernate 3.1.3 in production, but the problem occurs with 3.2.5 as well. A patched 3.1 release would be the best for us, but I'm not sure whether that is possible.

Thanks!
Carl-Eric Menzel
Senacor Technologies AG

Environment

Tested with Hibernate 3.1.3 and 3.2.5 on HSQL and Oracle 9, using JDK 1.4 and 1.6. The behavior is the same in each case.

Activity

Show:
VictorV
October 4, 2007, 10:15 AM

The Patch is by Carl-Eric, but since he is on vacation, I took the liberty to add it under my name

Carl-Eric Menzel
October 4, 2007, 12:48 PM

I'm on vacation and will be back on Monday, October 8th, but I'm watching this from here

Victor: Thanks anyway, because I don't have the patch here on my laptop.

Steve Ebersole
October 12, 2007, 5:39 PM

Thanks for researching this; your appraisal was spot on.

However, to me I think the natural place to correct this is actually in org.hibernate.engine.StatefulPersistenceContext#getOwnerId. This is called into from org.hibernate.property.BackrefPropertyAccessor.BackrefGetter#getForInsert at the point it is trying to determine the appropriate FK value to use when inserting the new collection element.

Steve Ebersole
October 17, 2007, 7:10 AM

fixed on trunk / 3.2

Steve Ebersole
March 21, 2011, 7:05 PM

Bulk closing stale resolved issues

Assignee

Steve Ebersole

Reporter

Carl-Eric Menzel

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Affects versions

Priority

Major
Configure