We have a big application using Tapestry and Hibernate (3.0.5). We are using Hibernate-dependent objects directly from Tapestry code. We do not use transactions. Now we get occasional NonUniqueObjectExceptions in different places and sometimes updates are not stored in database properly. The problems are not easy to reproduce, so any hints how to get rid of these problems are very welcome!

Thanks in advance!

Please understand that we don't know what's your application and what it does.
Without stack traces and/or code snippets we cannot help you. I think the meaning of the exception is clear : sometimes you violates a uniqueness constraint : why and where that's the problem. Maybe you can have some clues in your stack trace.
It seems that it is a concurrency problem

I was kind of hoping that somebody has met similar problems in using Hibernate and Tapestry. We don' know why there is an object with the same id in Hibernate cache (there shouldn't be!), but it's probably related to the way how Tapestry handles its pages.

Don't blame another framework until you are sure that your code is correct
Concurency problems are hard to find and solve. You say that you are not using transactions : maybe this is the problem.
Be sure to investigate all the possibilities. I am sure there is a lot of users using hibernate an tapestry without problems

Hi scesbron,

Implements Hash Code and equals method in your persistent object. Not sure ,It might help you. Second solution is that instead of use saveOrUpdate use merge but don’t forget to use return reference of merge. That would increase your line of code. As for as I know none other solution are available
Basic thing you should understand that why it is coming. It use to come if you have two reference of object with same ID value. So if you are properly handing these reference then it would not come.

Thanks dharmendra!

We already have hashCode and equals implemented in the base class:

// ----------------------------------------------------------------------
// Equality and hashcode calculations

private int m_hashCode = Integer.MIN_VALUE;

// Calculate hashcode - this is done like this since id cannot be used to calculate it
// May be null for new objects and hash code should not change on save/load cycle...
public int hashCode()
{
if (m_hashCode == Integer.MIN_VALUE){
String tmp = dateToString(m_created, "yyyyMMddHHmmss", null);
m_hashCode = tmp.hashCode();
// log.fatal("hashCode(): " + m_hashCode + ", str=" + tmp + ", date=" + m_created);
}
return m_hashCode;
}

/**
* Simple "common" equality comparison.
*
* @see java.lang.Object#equals(java.lang.Object)
*/
public boolean equals(Object other)
{
boolean result = false;

if (other == null) {
result = false;
}
else if (this == other) {
result = true;
}
else if ((this.getId() == null) || ((VOBase) other).getId() == null) {
result = false;
}
else {
result = this.getId().equals(((VOBase) other).getId());

// Check that business object is of the same type...
if (result) {
String myName = ((VOBase) this).getObjectModelName();
String otherName = ((VOBase) this).getObjectModelName();
result = myName.equals(otherName);
}
}

// log.fatal("equals: (" + this + " == " + other + ") = " + result);

return result;
}

You suggested merge instead of saveOrUpdate, does this have any side effects? We can try that. What did you mean by "using return reference of merge"?

I noticed that there seems to be a bug

String otherName = ((VOBase) this).getObjectModelName();

should be

String otherName = ((VOBase)other).getObjectModelName();

This might explain some of the problems, at least...

Hi MarttiH
merge has only drawback that you will have to use return reference further. Because passed reference does not updated version after merge.

Unfortunately correcting the above bug didn't help. The system still behaves in a random manner - as if there were several different copies of the same object in the session cache and one of them is chosen by random. Is there any way to dump the contents of the session cache?

Right... http://www.hibernate.org/Documentation/ ... CommitMode