Replace our ID generator with Hibernate technology

Our current ID generator has some major drawbacks:
1.) When a customer has problems in his cluster configuration or if there is a network problem and JGroups starts to shun and isolate nodes, then the ID generator returns the same IDs on both nodes.
2.) The ID generator always selects the current maximum ID of a table, BUT this one could have been already used previously, just that the user deleted the content before publishing. If the server is restarted then, the same IDs are produced again. This way, the information in the audit_log is no more consistent, so log based queries will be wrong.

The proper way of creating unique IDs is to use database technology. Many databases support sequences or similar. Hibernate since version 3.2.3 has some useful enhanced ID generator http://www.hibernate.org/hib_docs/reference/en/html/mapping.html#mapping-declaration-id-enhanced.

It makes use of sequences if the database supports it, and if the database does not support it, they transparently create a new table with the same functionality as sequences. This way our code will be portable.

Due to a threading bug with their optimizers (duplicate ID creation bug due to non-threadsafe programming), the feature can only reliably be used from Hibernate 3.2.6 onwards (see: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2928 ), which is exactly the version we use in Andromeda, so I think we should go for replacing the ID generator.

For compund identifiers, Hibernate does not support simple IDGeneration by mapping. For these cases (compound IDs) we would have to call their new ID generator out of our ID Generation service. For the IDs, which are not compound, we could let Hibernate completely take care of creating the IDs without our service.

There is still a question, if we should support dynamic setting of the initial values for sequences in order to migrate existing databases to the new ID generator. If it can be done easily we should consider that, otherwise we could also allow setting a common initial value by configuration.