Mystery solved!
My original suspicion was correct in that somewhere the app was attemting
to update the database before or while onValidate() was doing it's thing.
It wasn't BeanEditForm however, it was Hibernate jumping in the way. Part
of the stack trace:
org.hibernate.event.internal.DefaultAutoFlushEventListener onAutoFlush()
DefaultAutoFlushEventListener.java 62
org.hibernate.internal.SessionImpl autoFlushIfRequired() SessionImpl.java
1205
org.hibernate.internal.SessionImpl list() SessionImpl.java 1262
org.hibernate.internal.QueryImpl list() QueryImpl.java 101
org.hibernate.internal.AbstractQueryImpl uniqueResult()
AbstractQueryImpl.java 905
com.optomus.harbour.dal.HibernateCrudServiceDAO findUniqueWithNamedQuery()
HibernateCrudServiceDAO.java 90
Hibernate has identified that there are uncommitted changes to one of the
bound model instances. The auto flush is attempting to commit that to the
database.
The solution is to add "setFlushMode(FlushMode.MANUAL)" to my
findUniqueWithNamedQuery() method:
public <T> T findUniqueWithNamedQuery(String queryName, Map<String,
Object> params)
{
Set<Entry<String, Object>> rawParameters = params.entrySet();
Query query = session.getNamedQuery(queryName);
for (Entry<String, Object> entry : rawParameters)
{
query.setParameter(entry.getKey(), entry.getValue());
}
return (T) query.setFlushMode(FlushMode.MANUAL).uniqueResult();
}
This default Hibernate behaviour potentially interferes whenever
BeanEditForm is used to update a record. It seems to catch many Hibernate
users out. A valuable lesson learned that I shan't forget. :-)
Thanks & regards,
Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
