Currently the IncrementGenerator is not cluster-safe as it fetches the currently greatest Id in a separate transaction.

By simply changing this behavior to fetch the greatest id in the current transaction, IncrementGenerator can be made cluster-safe:


Of course, this causes the underlying user-created transaction to be initiated immediately, instead of when Commit() is called. This will in turn cause less concurrency in operations on affected tables, but as IncrementGenerator currently cannot handle concurrency at all, this is IMO not a great loss.

Is there a reason not to implement this behavior that I have not thought of?

(note: code above assumes a transaction has been created)

IncrementGenerator was meant to serve only as a simple generator for testing purposes, not for production use. In production, other generators should be used.

Agreed, it is not an optimal solution for id generation.

But, I am currently working in a project where exactly that solution is used. I would like to introduce the use of NHibernate but there is opposition to the change of the current id-generation implementation. Thus it is easier for me to adapt NHibernate to our system rather than the other way around.

Would it be possible to introduce my suggested changes into the code base, either into IncrementGenerator or into a new generator class, or should I just continue using my altered fork of IncrementGenerator?

I think it would be best for you to just use your implementation. If you would like the change to be considered for the official code base, please create a JIRA issue.

I have my own Id generator and you can do the same without modifying the current code - I would think that would be best. Even if the changes were to be considered for NH Core it probably could be implemented as a parameter to the Id generator or as another generator altogether so that people already using this one wouldn't be affected.

JMHO...

benster

Yes, I will use a custom id generator, but i think that cluster-safe behavior should be implemented, through options or alternate classes, in all id generators currently in NH Core. In that way, backwards-compatability is kept and each user can decide which behavior they want to use.

This is perhaps not very important for many applications that use NHibernate as the sole database interface, but for distributed solutions with different, multithreaded, applications on different platforms accessing the same database, it is critical.