The problem in our application I am asking about deals with a builder process for creating a survey.

Create and persist survey
Survey survey = createDefaultSurvey();
Long id = session.save(survey);
return survey;

Alternative: Create and persist survey
Survey survey = createDefaultSurvey();
Long id = session.save(survey);
Survey persistedSurvey = session.load(Survey.class, id);
return persistedSurvey;

The survey returned from the previous lines of code is passed around in the servlet session for the duration of the build process. The hibernate session object is also stored in the servlet session for the duration of the build process. (It is bound and unbound each request, no problems with that) However, when the session is flushed, all changes made to survey since session.save, aren't reflected. It's as if transitive persistence isn't working. However, other parts of our application aren't having these problems.

As can be seen in the logging output below, the survey object has an non-null answerInput, startDate, and endDate. However, null is what the values are for the sql inserts.

Any help or direction would be much appreciated.

Hibernate version:
3.2.5.ga

Mapping documents:
<hibernate-mapping>
<class name="edu.wvu.enketo.core.Survey" table="ENKETO_SURVEY">
<cache usage="read-write"/>
<id name="id" column="ID">
<generator class="sequence">
<param name="sequence">ENKETO_SURVEY_SEQ</param>
</generator>
</id>
<property name="fixedDate" column="FIXED_DATE" type="date"/>
<property name="startDate" column="START_DATE" type="date"/>
<property name="endDate" column="END_DATE" type="date"/>
<property name="answerInputMethod" column="ANSWER_INPUT_METHOD"/>

<many-to-one name="metadata" column="METADATA_REF" cascade="all"/>

<many-to-one name="instructions" column="INSTRUCTIONS_REF"/>

<list name="segments" cascade="all-delete-orphan">
<key column="SURVEY_REF" not-null="true"/>
<list-index column="SEQUENCE_NUMBER"/>
<one-to-many class="edu.wvu.enketo.core.Segment"/>
</list>

<set name="responses" cascade="all-delete-orphan">
<key column="SURVEY_REF" not-null="true"/>
<one-to-many class="edu.wvu.enketo.core.SurveyResponse"/>
</set>

</class>

</hibernate-mapping>

Full stack trace of any exception that occurs:
Caused by: java.sql.BatchUpdateException: ORA-01400: cannot insert NULL into ("ESEI"."ENKETO_SURVEY"."ANSWER_INPUT_METHOD")

at oracle.jdbc.driver.DatabaseError.throwBatchUpdateException(DatabaseError.java:343)
at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10720)
at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:294)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)

Name and version of the database you are using:
Oracle 10.3

Debug log of survey right before commit
2008-03-13 21:03:46,544 [http-8084-Processor23] FATAL [edu.wvu.enketo.modules.builder.ui.EditSurveyBean|apply|103]- survey: {Survey:40033}
2008-03-13 21:03:46,547 [http-8084-Processor23] FATAL [edu.wvu.enketo.modules.builder.ui.EditSurveyBean|apply|104]- answertype: Paper
2008-03-13 21:03:46,548 [http-8084-Processor23] FATAL [edu.wvu.enketo.modules.builder.ui.EditSurveyBean|apply|105]- startdate: Wed Mar 19 00:00:00 GMT 2008
2008-03-13 21:03:46,548 [http-8084-Processor23] FATAL [edu.wvu.enketo.modules.builder.ui.EditSurveyBean|apply|106]- enddate: Wed Mar 26 00:00:00 GMT 2008
2008-03-13 21:03:46,549 [http-8084-Processor23] FATAL [edu.wvu.enketo.modules.builder.ui.EditSurveyBean|apply|107]- metadata: {metadata:{sei:termCode|{200803}},{sei:wvuid|{700233111}},{sei:crn|{20021}}}
2008-03-13 21:03:46,549 [http-8084-Processor23] FATAL [edu.wvu.enketo.modules.builder.ui.EditSurveyBean|apply|108]- segments: [{Segment:null}, {Segment:null}, {Segment:null}, {Segment:null}, {Segment:null}, {Segment:null}, {Segment:null}]


Debug level Hibernate log excerpt:
2008-03-13 21:03:47,926 [http-8084-Processor23] DEBUG [org.hibernate.jdbc.AbstractBatcher|log|401]- insert into ESEI.ENKETO_SURVEY (FIXED_DATE, START_DATE, END_DATE, ANSWER_INPUT_METHOD, METADATA_REF, INSTRUCTIONS_REF, ID) values (?, ?, ?, ?, ?, ?, ?)
2008-03-13 21:03:47,926 [http-8084-Processor23] DEBUG [org.hibernate.type.NullableType|nullSafeSet|126]- binding null to parameter: 1
2008-03-13 21:03:47,927 [http-8084-Processor23] DEBUG [org.hibernate.type.NullableType|nullSafeSet|126]- binding null to parameter: 2
2008-03-13 21:03:47,927 [http-8084-Processor23] DEBUG [org.hibernate.type.NullableType|nullSafeSet|126]- binding null to parameter: 3
2008-03-13 21:03:47,927 [http-8084-Processor23] DEBUG [org.hibernate.type.NullableType|nullSafeSet|126]- binding null to parameter: 4
2008-03-13 21:03:47,928 [http-8084-Processor23] DEBUG [org.hibernate.type.NullableType|nullSafeSet|133]- binding '228092' to parameter: 5
2008-03-13 21:03:47,928 [http-8084-Processor23] DEBUG [org.hibernate.type.NullableType|nullSafeSet|133]- binding '1' to parameter: 6
2008-03-13 21:03:47,928 [http-8084-Processor23] DEBUG [org.hibernate.type.NullableType|nullSafeSet|133]- binding '40033' to parameter: 7

Hibernate was working as designed. The problem was a combination of my not fully understanding the hibernate process, a database constraint, and an improperly configured hibernate session.

Problem 1.
I was calling session.save(survey) then modifing the survey. Because of this, hibernate does an insert with lots of nulls (because the initial survey object I used had nulls). It then does updates to insert the modified values.

Problem 2.
Normally Problem 1 isn't an issue. However on our database, we had a not-null constraint. This was the actual error I was seeing. The solution was to change the constraint to be (initially deferred). With initially deferred constraints, they aren't checked until commit.
("initially deferred" is how constraints are initially deferred in oracle. I don't know if there is different terminology in other databases.)

Problem 3.
Our hibernate session was configured with FlushMode.AUTO (default). This means a commit is issued after each sql command. Because of this, it didn't matter if our constraint was initially deferred or not. We changed our flush mode to FlushMode.MANUAL, but FlushMode.COMMIT should work as well.