Apparently, if I 'save' a new object, change the data, and then flush it generates an insert with the initial values from the 'save' and then an update with the current data.

Is there a good reason for this behavior?

We made the change below to sessionimpl, which effectively replaces an insert with the new data rather than doing both an insert and an update when flushing a new object. It is a requirement for us because the insert and update are using different lock modes, which causes frequent deadlocks.

Is the change below a viable patch, or would it cause problems in areas we're unaware of?

Thanks for your help!
Jenica


--- SessionImpl.java 4 Feb 2004 23:59:27 -0000 1.4
+++ SessionImpl.java 20 Feb 2004 19:53:00 -0000 1.5
@@ -1,4 +1,4 @@
-//$Id: SessionImpl.java,v 1.4 2004/02/04 23:59:27 ron Exp $
+//$Id: SessionImpl.java,v 1.5 2004/02/20 19:53:00 ron Exp $
package net.sf.hibernate.impl;

import java.io.IOException;
@@ -2534,13 +2534,30 @@

checkNullability(values, persister, true);

- // schedule the update
- updates.add(
- //new Key(entry.id, persister),
- new ScheduledUpdate(entry.id, values, dirtyProperties, entry.loadedState, entry.version, nextVersion, object, updatedState, persister, this)
- //note that we intentionally did _not_ pass in currentPersistentState!
- );
-
+ // insert already scheduled?
+ // then just switch it!
+ boolean alreadyInserted = false;
+ int index = 0;
+ if ( insertions.size() > 0) {
+ for (Iterator i = insertions.iterator(); i.hasNext(); index++) {
+ ScheduledInsertion si = (ScheduledInsertion) i.next();
+ if (si.getInstance().equals(object)) {
+ alreadyInserted = true;
+ break;
+ }
+ }
+ }
+ if (alreadyInserted) {
+ insertions.remove(index);
+ insertions.add(index, new ScheduledInsertion( entry.id, values, object, persister, this ) );
+ } else {
+ // schedule the update
+ updates.add(
+ //new Key(entry.id, persister),
+ new ScheduledUpdate(entry.id, values, dirtyProperties, entry.loadedState, entry.version, nextVersion, object, updatedState, persister, this)
+ //note that we intentionally did _not_ pass in currentPersistentState!
+ );
+ }
}

if (status==DELETED) {

Expected Hibernate behavior (we have debated whether this is really correct or not!) is that the INSERT statement will insert exactly the data that was set when save() was called. This gives the user a bit finer grained control, especially in a context where there are triggers etc. However, if you are not careful, it could perform badly.

Just in case you ever have the debate again --

The trouble it's causing us is that the insert requires a less restrictive lock than the update, so if we have two threads doing the same thing the first gets a row-level write lock, the second gets a row-level write lock, and then they deadlock on the update because the update is asking for a table lock.

Jenica

eh? how can they deadlock? This is all in the same session, right? Deadlocks only occur between concurrent txns.

Two transactions, both doing the same sort of thing:

TX1: insert into incident ... (row lock)
TX2: insert into incident ... (row lock)
TX1: (misc other inserts)
TX2: (misc other inserts)
TX1: update incident (requires table lock, tx2 has row lock so can't acquire it)
TX2: update incident (requires table lock, tx1 has row lock so can't acquire it)

Does that make sense? If it just does the insert, it needs the same level of lock for the whole transaction. Doing both makes it upgrade the lock halfway through, causing deadlock potential.

Jenica

It acquires a table-level lock for an update??!!

Thats bizarre! What txn isolation level are we talking about here?

I've tried TRANSACTION_READ_COMMITTED and TRANSACTION_READ_UNCOMMITTED both - it doesn't seem to make any difference on the write locks.

What database is that? This sounds really freaky to me.

DB2 UDB 7.2. I thought it was really odd too - but it deadlocks every time on that update and the snapshot of the locks show a requested "IX" table level lock for the table we're updating.

I suggest you ask in some DB2 forum about this behavior, it doesn't seem right to me.

To avoid the INSERT-then-UPDATE, simply fully initialize the object before saving it.

For those looking around, a co-worker and I have created patch for Hibernate 3.5.6-Final to accomplish this. You can find the whole Hibernate core project that we patched on GitHub:

http://github.com/sfraser/Hibernate-Cor ... nhancement

With more and more uses of an extended persistence context (session-per-converstaion), this behavior seems to be a feature that should be a configurable element of Hibernate. Is there a reason why it hasn't been?



With an extended persistence context, this may not always be possible or fit the use cases of the application.

We've found this problem to occur mostly with Oracle when using sequence based id generation. In HSQL, the INSERT happens immediately after a call to merge and is not scheduled to execute when the flush occurs.

Thanks for the patch! We are considering upgrading to Hibernate 3 so this will be very useful for us.

Jenica