Hibernate version: 2.1.6

I am having a hard time with those NonUniqueObjectExceptions.

I have a detached object instance that I want to reattach. In some cases there's already another instance of the object in the current session, so that I get the NonUniqueObjectException. That's quite correct behaviour.

Unfortunately I did not find any way how to check whether the another instance of the detached object is already present in the cache, because session.contains() always returns false.

I debugged into this and found out that contains() does the following:



Finally this ends in HashMap.containsKey(), which calls HashMap.hash(), which calls HashMap$IdentityKey.hashCode().

And here's the real problem:


This method calls identityHashCode, which totally omits any hashCode() implementation in my Hibernate persisted beans. Thus session.contains() will always return false, except if the detached object and the instance that is contained in the session have the same identityHashCode, which is impossible.

Maybe I am wrong, but isn't this a major problem with the Hibernate implementation.....

Got the same problem over here...

Use session.saveOrUpdateCopy(). Unfortunately, it does't work properly with cascading (known issue in JIRA) in Hibernate 2.1.x.

Is the Session.contains() impl. desireable or even intentional?
Should it be regarded as a bug?

Finland in December?

File a bug report.

Will file a report.

See you in Helsinki (Finland) in December?



Regards
/JVK

Forget that, its not a bug. The comparision uses the identifiers to find out if an object already exists in a Session. Thats nothing you could override in your domain classes.

Doesn't work.

flow:

Session session = SessionFactory.createSession();
Object X = session.get(PersistentPOJO.class,new Long(1));
session.close();
session = SessionFactory.createSession();
Object Y = session.get(PersistentPOJO.class,new Long(1));
session.lock(X); //No way dude

if(session.contains(X)) //returns false although it shouldn't
session.lock(X);
session.close();

It is a detached object, hence it is not "in" the session. The semantics are quite correct and natural.

X and Y are 2 instances of the same row in the table.
Therefor it would make sense to do an equals() comparison in contains().

Otherwise the problem becomes that you have to lock() _all_ detached objects at the beginning of every request (if you're down with the session-per-request-with-detached-objects"-style). The you have to centralize references to all detached object, because if you try to lock a detached object after doing any kind of retrieval, you'll be sure to be in trouble.

I can understand that you want to be able to do identity-comparison, but the problem is that in my example, X and Y ARE the very same object, and Hibernate doesn't take that into consideration, even though I've specified compareTo(), equals() and hashCode().

Is there any other possible solution to this dilemma that I've overseen?

IOn my example, Having X as a detached instance, and Y as a persistant instance of the same database row, wouldn't

x = s.lock(x,LockMode.NONE);

be a much better solution?

then s.lock(Object o, LockMode mode)
would do first an identifier-lookup (see if the 1st level cache contains a persistent object with getClass() == o.getClass() && id.equals(o.getId()),
then do a persistentObjectInCache.equals(o), and if it returns true, it'd return a reference to the persistent object, else, do the normal locking and return a reference to o.

That'd be much better sinch saveOrUpdateCopy() doesn't work with cascading.

I'm having the same problem with the session-per-request pattern.

There are always detached objects from the last session and I can't update them because there might already be another instance of it in the current session.

I did not find any way to determine if there's already such other instance in the session. Session.contains() is quite useless for this.

We would need something like session.containsObjectWithId(Class, Id).