Index: src/main/java/org/jbpm/pvm/internal/model/DefaultIdGenerator.java
===================================================================
--- src/main/java/org/jbpm/pvm/internal/model/DefaultIdGenerator.java	(revision 5251)
+++ src/main/java/org/jbpm/pvm/internal/model/DefaultIdGenerator.java	(working copy)
@@ -37,22 +37,6 @@
 
   public String createId(ProcessDefinition processDefinition, Execution parent, ExecutionImpl execution) {
 
-    Session session = Environment.getFromCurrent(Session.class);
-    session.save(execution);
-    // the next flush is introduced because of the following situation:
-    // for hsqldb: id generation is done by inserting and then reading the id value
-    // for db's that have separate id generators (postgres, oracle, mysql), the previous 
-    // save will only make hibernate generate a new id, but the insert is not yet done
-    // Then the following scenario might happen:
-    //  * the new execution is added to collection of the parent execution
-    //  * the parent execution ends, causing the new child to be removed from the collection
-    //  * the child executions collection's cascade is set to all-delete-orphan so 
-    //    we expect hibernate to delete it
-    //  * for some reason, then hibernate gets confused and still inserts the 
-    //    execution afterwards.
-    session.flush();
-    
-
     String base = null;
     if (parent!=null) {
       base = parent.getId(); 
@@ -79,6 +63,22 @@
     
     if (log.isDebugEnabled()) log.debug("generated execution id "+executionId);
     
+	execution.setId(executionId);
+	Session session = Environment.getFromCurrent(Session.class);
+    session.save(execution);
+    // the next flush is introduced because of the following situation:
+    // for hsqldb: id generation is done by inserting and then reading the id value
+    // for db's that have separate id generators (postgres, oracle, mysql), the previous 
+    // save will only make hibernate generate a new id, but the insert is not yet done
+    // Then the following scenario might happen:
+    //  * the new execution is added to collection of the parent execution
+    //  * the parent execution ends, causing the new child to be removed from the collection
+    //  * the child executions collection's cascade is set to all-delete-orphan so 
+    //    we expect hibernate to delete it
+    //  * for some reason, then hibernate gets confused and still inserts the 
+    //    execution afterwards.
+    session.flush();
+
     return executionId;
   }
 }