What would cause NHibernate to return an invalid identity selection when using JET?

Question

Our application (sadly) uses an MDB back-end database (I.e. JET engine).

One of the items being persisted to the database is an "event" object. The object is persisted to a table with an ID (EventLogID) that is an Autonumber field. The NHibernate mapping is as follows:

<class name="EventLogEntry" table="tblEventLog" proxy="IEventLogEntry">
  <id name="Id">
    <column name="EventLogID" not-null="true" />
    <generator class="native" />
  </id>
  <property name="Source" column="ErrorLogSource" />
  <property name="Text" column="EventLogText" />
  <property name="Time" column="EventLogTime" />
  <property name="User" column="UserID" />
  <property name="Device" column="EventDeviceID" />
</class>

According to the log file, on some occasions when NHibernate attempts to obtain the identity, it receives the value "0". Later, when Flush is called, NHibernate suffers from an assertion failure.

Can anyone suggest why this might be happening? Better yet, can anyone suggest how to fix it?

Regards, Richard

Answer 1

It could be that the default 'connection-release-mode' configuration setting is the cause of the problems.

A while ago, I ran into a similar issue, and I found that changing the connection.release-mode to 'on_close' (instead of the default after_transaction) solved the issue.

More information can be found on my blog

edit: as I'm thinking of it, perhaps it can be solved without changing the release-mode as well; what happens if you use a transaction to save your event ?

The default release-mode is after transaction, so I'm thinking; perhaps when you use an explicit transaction, the connection will only be closed after the transaction. The question offcourse is, will NHibernate try to retrieve the primary key that has been given to the object inside this transaction, or will it use another transaction ...

If it does not work, then changing the release-mode will solve your problem as well, but it is maybe not the best option.
I think the best option/solution, is to use an explicit transaction first, and see if this solves the problem...