Here, I have a problem that I minimized into 2 classes and hsqldb for easy re-generation of the issue. I have a List of Bars under Foo. It is declared to be cascade="all-delete-orphan" and inverse="true". I create a new "Foo" and add a "Bar" under it. Then I try to save the "Foo". If a problem occurs during the save, I rollback the transaction and close the session. If nothing goes wrong, Hibernate understands that it should issue an "insert" for the "Bar" and everything works well. If for some reason the operation fails, let it be a database constraint or a ValidationFailure, in the next attempt to save the "Foo", the "Bar" is accepted as inserted and Hibernate issues an "update". Naturally it cannot find a row to update and the update fails and Hibernate generates the Error: Could not synchronize database state with session.
Problem still occurs in both cases of "Foo" as a new one or a "Foo" that is already in the database and loaded for an update.
Problem occurs both in Sybase ASA and hsqldb.
Is it something that I am doing wrong or missing?
Best regards,
Levent Aksu

Hibernate version:
2.1.4 to 2.1.6
Mapping documents:

<hibernate-mapping>
<class name="Foo">
<id name="id" type="long" unsaved-value="0">
<generator class="hilo">
<param name="max_lo">0</param>
<param name="table">key_Foo</param>
</generator></id>
<property name="a" length="50" type="string"/>
<property name="b" type="double"/>
<list name="bars" inverse="true" cascade="all-delete-orphan" lazy="true">
<key column="foo"/>
<index column="sortorder"/>
<one-to-many class="Bar"/>
</list>
</class>

<class name="Bar">
<id name="id" unsaved-value="0" type="long">
<generator class="hilo">
<param name="max_lo">0</param>
<param name="table">key_Bar</param>
</generator></id>
<many-to-one name="foo" class="Foo" not-null="true" />
<property name="sortorder" type="int"/>
<property name="c" length="50" type="string"/>
<property name="d" type="double"/>
</class>
</hibernate-mapping>

Code between sessionFactory.openSession() and session.close():

Foo f=new Foo();
f.setA("aaa");
f.setB(3);

Bar b=new Bar();
b.setC("ccc");
// Bar implements Validatable and throws
// ValidationFailure if D is less than 10
b.setD(5); // Try an invalid value
b.setFoo(f);
f.getBars().add(b);
s1=sf.openSession();
try{
t = s1.beginTransaction();
s1.save(f);
t.commit();
} catch(HibernateException he){ // it's rejected as expected
System.out.println("Exception occured:"+he.getMessage());
if (t!=null)
t.rollback();
} finally {
s1.close();
}

b.setD(15); // let's correct it

s2=sf.openSession();
try{
t = s2.beginTransaction();
s2.save(f);
t.commit();
} catch(HibernateException he){
System.out.println("Exception occured:"+he.getMessage());
if (t!=null)
t.rollback();
} finally {
s2.close();
}


Full stack trace of any exception that occurs:
Included in the log below

Name and version of the database you are using:
Both with hsqldb 1.7.2 and Sybase ASA 9.0.1

Debug level Hibernate log excerpt:

06:27:04,140 INFO ReflectHelper:186 - reflection optimizer disabled for: Bar, NullPointerException: null
06:27:04,328 DEBUG SessionFactoryObjectFactory:39 - initializing class SessionFactoryObjectFactory
06:27:04,343 DEBUG SessionFactoryObjectFactory:76 - registered: 40288182fe562f2600fe562f28880000 (unnamed)
06:27:04,343 INFO SessionFactoryObjectFactory:82 - Not binding factory to JNDI, no JNDI name configured
06:27:04,343 DEBUG SessionFactoryImpl:195 - instantiated session factory
06:27:04,421 DEBUG SessionImpl:555 - opened session
06:27:04,421 DEBUG JDBCTransaction:37 - begin
06:27:04,437 DEBUG DriverManagerConnectionProvider:84 - total checked-out connections: 0
06:27:04,437 DEBUG DriverManagerConnectionProvider:90 - using pooled JDBC connection, pool size: 0
06:27:04,437 DEBUG JDBCTransaction:41 - current autocommit status:false
06:27:04,437 DEBUG DriverManagerConnectionProvider:84 - total checked-out connections: 1
06:27:04,437 DEBUG DriverManagerConnectionProvider:100 - opening new JDBC connection
06:27:04,437 DEBUG DriverManagerConnectionProvider:106 - created connection to: jdbc:hsqldb:file:data/prob, Isolation Level: 1
06:27:04,515 DEBUG DriverManagerConnectionProvider:120 - returning connection to pool, pool size: 1
06:27:04,515 DEBUG TableHiLoGenerator:62 - new hi value: 14
06:27:04,515 DEBUG SessionImpl:778 - generated identifier: 15
06:27:04,515 DEBUG SessionImpl:825 - saving [Foo#15]
06:27:04,515 DEBUG Cascades:497 - processing cascades for: Foo
06:27:04,531 DEBUG Cascades:506 - done processing cascades for: Foo
06:27:04,546 DEBUG WrapVisitor:81 - Wrapped collection in role: Foo.bars
06:27:04,546 DEBUG Cascades:497 - processing cascades for: Foo
06:27:04,562 DEBUG Cascades:524 - cascading to collection: Foo.bars
06:27:04,562 DEBUG Cascades:113 - cascading to saveOrUpdate()
06:27:04,562 DEBUG Cascades:312 - id unsaved-value: 0
06:27:04,562 DEBUG SessionImpl:1387 - saveOrUpdate() unsaved instance
06:27:04,562 DEBUG DriverManagerConnectionProvider:84 - total checked-out connections: 1
06:27:04,562 DEBUG DriverManagerConnectionProvider:90 - using pooled JDBC connection, pool size: 0
06:27:04,562 DEBUG DriverManagerConnectionProvider:120 - returning connection to pool, pool size: 1
06:27:04,562 DEBUG TableHiLoGenerator:62 - new hi value: 11
06:27:04,578 DEBUG SessionImpl:778 - generated identifier: 12
06:27:04,578 DEBUG SessionImpl:825 - saving [Bar#12]
Exception occured:d must be greater than 10
06:27:04,578 DEBUG JDBCTransaction:82 - rollback
06:27:04,578 DEBUG SessionImpl:585 - transaction completion
06:27:04,578 DEBUG SessionImpl:573 - closing session
06:27:04,578 DEBUG SessionImpl:3336 - disconnecting session
06:27:04,578 DEBUG DriverManagerConnectionProvider:120 - returning connection to pool, pool size: 2
06:27:04,578 DEBUG SessionImpl:585 - transaction completion
06:27:04,578 DEBUG SessionImpl:555 - opened session
06:27:04,578 DEBUG JDBCTransaction:37 - begin
06:27:04,593 DEBUG DriverManagerConnectionProvider:84 - total checked-out connections: 0
06:27:04,593 DEBUG DriverManagerConnectionProvider:90 - using pooled JDBC connection, pool size: 1
06:27:04,593 DEBUG JDBCTransaction:41 - current autocommit status:false
06:27:04,593 DEBUG DriverManagerConnectionProvider:84 - total checked-out connections: 1
06:27:04,593 DEBUG DriverManagerConnectionProvider:90 - using pooled JDBC connection, pool size: 0
06:27:04,593 DEBUG DriverManagerConnectionProvider:120 - returning connection to pool, pool size: 1
06:27:04,593 DEBUG TableHiLoGenerator:62 - new hi value: 15
06:27:04,593 DEBUG SessionImpl:778 - generated identifier: 16
06:27:04,593 DEBUG SessionImpl:825 - saving [Foo#16]
06:27:04,609 DEBUG Cascades:497 - processing cascades for: Foo
06:27:04,609 DEBUG Cascades:506 - done processing cascades for: Foo
06:27:04,609 DEBUG Cascades:497 - processing cascades for: Foo
06:27:04,609 DEBUG Cascades:524 - cascading to collection: Foo.bars
06:27:04,609 DEBUG Cascades:113 - cascading to saveOrUpdate()
06:27:04,609 DEBUG Cascades:312 - id unsaved-value: 0
06:27:04,609 DEBUG SessionImpl:1392 - saveOrUpdate() previously saved instance with id:12
06:27:04,609 DEBUG SessionImpl:1440 - updating [Bar#12]
06:27:04,609 DEBUG Cascades:506 - done processing cascades for: Foo
06:27:04,625 DEBUG JDBCTransaction:59 - commit
06:27:04,625 DEBUG SessionImpl:2246 - flushing session
06:27:04,625 DEBUG Cascades:497 - processing cascades for: Foo
06:27:04,625 DEBUG Cascades:524 - cascading to collection: Foo.bars
06:27:04,625 DEBUG Cascades:113 - cascading to saveOrUpdate()
06:27:04,625 DEBUG SessionImpl:1372 - saveOrUpdate() persistent instance
06:27:04,625 DEBUG Cascades:506 - done processing cascades for: Foo
06:27:04,625 DEBUG SessionImpl:2439 - Flushing entities and processing referenced collections
06:27:04,625 DEBUG SessionImpl:2884 - Collection found: [Foo.bars#16], was: [<unreferenced>]
06:27:04,640 DEBUG SessionImpl:2533 - Updating entity: [Bar#12]
06:27:04,640 DEBUG SessionImpl:2780 - Processing unreferenced collections
06:27:04,640 DEBUG SessionImpl:2794 - Scheduling collection removes/(re)creates/updates
06:27:04,640 DEBUG SessionImpl:2270 - Flushed: 1 insertions, 1 updates, 0 deletions to 2 objects
06:27:04,640 DEBUG SessionImpl:2275 - Flushed: 1 (re)creations, 0 updates, 0 removals to 1 collections
06:27:04,640 DEBUG Printer:75 - listing entities:
06:27:04,656 DEBUG Printer:82 - Bar{d=15.0, foo=Foo#16, sortorder=0, c=ccc, id=12}
06:27:04,656 DEBUG Printer:82 - Foo{a=aaa, bars=[Bar#12], b=3.0, id=16}
06:27:04,656 DEBUG SessionImpl:2359 - executing flush
06:27:04,656 DEBUG EntityPersister:453 - Inserting entity: [Foo#16]
06:27:04,656 DEBUG BatcherImpl:200 - about to open: 0 open PreparedStatements, 0 open ResultSets
06:27:04,656 DEBUG SQL:226 - insert into Foo (a, b, id) values (?, ?, ?)
Hibernate: insert into Foo (a, b, id) values (?, ?, ?)
06:27:04,656 DEBUG BatcherImpl:249 - preparing statement
06:27:04,656 DEBUG EntityPersister:388 - Dehydrating entity: [Foo#16]
06:27:04,656 DEBUG StringType:46 - binding 'aaa' to parameter: 1
06:27:04,656 DEBUG DoubleType:46 - binding '3.0' to parameter: 2
06:27:04,656 DEBUG LongType:46 - binding '16' to parameter: 3
06:27:04,671 DEBUG BatcherImpl:28 - Adding to batch
06:27:04,671 DEBUG BatcherImpl:50 - Executing batch size: 1
06:27:04,671 DEBUG BatcherImpl:207 - done closing: 0 open PreparedStatements, 0 open ResultSets
06:27:04,671 DEBUG BatcherImpl:269 - closing statement
06:27:04,671 DEBUG EntityPersister:648 - Updating entity: [Bar#12]
06:27:04,671 DEBUG BatcherImpl:200 - about to open: 0 open PreparedStatements, 0 open ResultSets
06:27:04,671 DEBUG SQL:226 - update Bar set foo=?, sortorder=?, c=?, d=? where id=?
Hibernate: update Bar set foo=?, sortorder=?, c=?, d=? where id=?
06:27:04,671 DEBUG BatcherImpl:249 - preparing statement
06:27:04,671 DEBUG EntityPersister:388 - Dehydrating entity: [Bar#12]
06:27:04,671 DEBUG LongType:46 - binding '16' to parameter: 1
06:27:04,671 DEBUG IntegerType:46 - binding '0' to parameter: 2
06:27:04,687 DEBUG StringType:46 - binding 'ccc' to parameter: 3
06:27:04,687 DEBUG DoubleType:46 - binding '15.0' to parameter: 4
06:27:04,687 DEBUG LongType:46 - binding '12' to parameter: 5
06:27:04,687 DEBUG BatcherImpl:28 - Adding to batch
06:27:04,687 DEBUG BatcherImpl:50 - Executing batch size: 1
06:27:04,687 DEBUG BatcherImpl:207 - done closing: 0 open PreparedStatements, 0 open ResultSets
06:27:04,687 DEBUG BatcherImpl:269 - closing statement
06:27:04,703 ERROR SessionImpl:2379 - Could not synchronize database state with session
net.sf.hibernate.HibernateException: Batch update row count wrong: 0
at net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:65)
at net.sf.hibernate.impl.BatcherImpl.executeBatch(BatcherImpl.java:126)
at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2421)
at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2372)
at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2240)
at net.sf.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:61)
at meyn.main(meyn.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:193)
at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:130)
at org.apache.tools.ant.taskdefs.Java.run(Java.java:705)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:177)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:83)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
at org.apache.tools.ant.Project.executeTargets(Project.java:1062)
at org.apache.tools.ant.Main.runBuild(Main.java:673)
at org.apache.tools.ant.Main.startAnt(Main.java:188)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:196)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:55)
Exception occured:Batch update row count wrong: 0
06:27:04,718 DEBUG JDBCTransaction:82 - rollback
06:27:04,718 DEBUG SessionImpl:585 - transaction completion
06:27:04,718 DEBUG SessionImpl:573 - closing session
06:27:04,718 DEBUG SessionImpl:3336 - disconnecting session
06:27:04,718 DEBUG DriverManagerConnectionProvider:120 - returning connection to pool, pool size: 2
06:27:04,718 DEBUG SessionImpl:585 - transaction completion

As I understand, after HibernateException instances of Foo and Bar are in the inappropriate state (IDs generated and assigned, and etc) -- you should not use them again. So your "let's correct it" is error-prone. "Item 46: Strive for failure atomicity" of Effective Java, does not work for hibernate objects.

Hibernate team and others, I am right?

As per the documentation, Hibernate session is not failure safe, because implementing atomicity for such a complex object with such complex re-entrant behavior is simply too much of a performance overhead.

Did I miss something?

Of course if a HibernateException is thrown I have to rollback and close transaction and session. But that's what laxus code ist doing. The second save atempt is done in a new session and transaction. So if he isn't doing funny things in its POJOs I excpect this to work.

Best Regards
Ernst

transaction is rolled back, SQL rows are not inserted, but the POJOs are in the broken state (e.g. they have got generated IDs, transaction rollback does not return the object to the original state). So you should not use broken POJOs, e.g. IDs are generated and assigned, repeated Session.save tries to update not existing objects (SQL update updates nothing) and even new session does not help.

the scenario here is a basic data entry in a master-detail relationship. User enters data, clicks "save", breaks a business rule, validate rejects, user corrects the data but cannot "save" in a second attempt. am I expecting too much. all my design is relying on the "cascade" feature, that is one "save" to the "Foo" and the whole map will be saved in unity.
i cannot tell at the moment if how I could make this to work in the second or third attempt. i cannot picture how to behave to the "Bars" down the hierarchy and of course real application consists of a more complex structure that is also deeper (e.g. each "Bar" has collections of "Snafus" etc.). because some of them could have received ids and some would not. and some would have acquired their IDs during the previous successful "save"s to the "Foo" which would be valid IDs.
any suggestions, workarounds?

I would like to suggest to use some kind of validator before session.save() call. If you use Struts, you already have something like FormBean.validate() method and common validation framework. Don't save not valid data.

read http://www.hibernate.org/hib_docs/reference/en/html/persistent-classes.html#persistent-classes-validatable
Unlike the callback methods of the Lifecycle interface, validate() might be called at unpredictable times. The application should not rely upon calls to validate() for business functionality.
I think about Validatable callback like about some kind of database constraint or run-time exception, that use cannot handle.

that user cannot handle.

Thanks for your patience with slow thinkg ernst. I just learned al lot about hibernate.

Don't forget to help others (C) Anthony :)

Regards

I kinda write my own framework for a simple two tier C/S system so checking before the data is sent is not a big issue for me.
however it is not always that efficient to solve all business rules on the client side. for example duplicates are best left to unique indexes or in some cases triggers are far efficient. since this is a framework. Or something lower than the business layer, in the data layer there might be an unforeseeable problem. For example a "deadlock victim" error simply requires the user to re-issue the transaction. Or anything could happen that the database may reject for some reason, say something related w/replication, backup, I don't know anything could happen and I would not prefer the data at the client be half-complete. When a transaciton is rolled back for whatever the reason is, everything should be back in its previous state.

What if I try to implement the functionality that Gavin told it would cost a performance overhead, externally and maybe in some future it may enter into Hibernate as an optional, default disabled, "be-warned-overhead- incurring" feature. Or at least it would be useful for someone else. Of course I would be required to step into some internals.
What do you guys think?
1) Is it somewhat possible?
2) Would it be an ambitious task to achieve for a guy like me who does not have any Hibernate internal knowledge
3) Do you think I am totally wrong and this is not necessary at all.
4) Or would you simply think that it would not worth the trouble?
Best Regards,
Levent Aksu
laxu

I don't know the answers, but I think even if somone can give you a 1) yes, 2) yes, this does not solve your requirement.

I think you expect that after a rollback everything is at the state it was before the transaction started.
Actually hibernate isn't doing the transaction stuff itself, it's realying on the transaction system you are using. Have a look at the source of JDBCTransaction.java, it simply wrapes the JDBC stuff. This means a rollback of the Hibernate transaction can only rollback those resources it manages. In the case of JDBC, the data manipulation you (or Hibernate :-) ) did via the JDBC API.

IMHO: What you are asking for is a transaction system which is able to rollback the JVM to a state it had in the past. Maybe this is doable, but chances are high, that you find yourself extending Java and writing your own JVM...

If everything only means your persisten classes, there's may be help. There's a comercial and proprietary ORM from http://www.corix.ch which comes with it's own transaction manager which manages also the transient state of the persistent classes. They are about to finish to port their ORM to JDO.

HTH
Ernst

"everything" is somewhat a carelessly chosen word of course. What I thought was something simpler: Hibernate knows when the transaction starts, it can keep track of objects that are assigned an id since the beginning of the transaction and can reset them to their "unsaved-value"s in case a rollback occurs. Provided "unsaved-value" is a reliable discriminator.
Of course that should be an optional feature as under some circumstances it may harm performance.
I am a Hibernate fan, and believer in open-source. I don't think I will consider anything else ;-)
Regards,
Levent Aksu

If you use remoting calls then you don't need any object state rollback. Else you could serialize or clone your object before trying to save/update/remove it and if you caught an exception use that cloned/serialized object for repeated operations. But I don't recommend you to use Object.clone(), there are some possible troubles with it, see Item 10 "Override clone judiciously" of "Effective Java".

About four questions. As I understand, Gavin does not want to add such complexity (object state rollback) to Hibernate. He is an architector and it is question to him :) if Hibernate needs such functionality.

Regards

But that approach clone or serialize before save/update/remove is a performance overhead.