Hibernate version:
3.2.2 GA

Seems to be a small typo on line 3718 in AbstractEntityPersister (trunk and 3.2.2 GA) which makes exceptions during property generation being logged but not thrown:



There should be a throw in there I guess. :)



If this is intentional (might be, of course), is there any way to detect these kinds of exceptions?

OK, elaborating a bit:

This bug will not be noticeable in most cases and is probably why it hasn't been detected / fixed so far. The method in question (processGeneratedProperties) is used for retrieving properties that are marked as "generated" in the mapping document / annotations - in other words any value that the database provides and is considered "read-only" from the Hibernate application's point of view.

The generated value is retrieved by an extra select statement executed by Hibernate after an entity has been inserterd and / or updated (according to how the generated property is flagged). In my particular case, a property (not a key) is marked as generated="insert", so after Hibernate inserts a new entity to the database, it will immediately do a select and set the generated property to the value the database returns.

Only in rare cases will this select fail in any way - in fact, I cannot think of any situations other than mapping errors (e.g getInt on a CHAR column) that can cause errors in this last select. That is in addition to my situation - a deadlock.

My entity class uses uuid.hex generator for the PK, but at one point, we introduced a second unique key due to purely aestethic reasons. This is a SQL Server identity column. Since we don't do any explicit table locking during the inserts, we end up with deadlocks every time the following happens:



SQL Server throws an error to indicate the deadlock, but due to the missing throw in the processGeneratedProperties-method, it is never shown to the process doing the insert. The generated property is not set and retains it's null (or 0 in case of a primitive) without the business logic ever knowing that the entity could not be saved.

Our solution to this is simple, we don't care about having "holes" in the identity sequence, so setting the transaction isolation to read_uncommited for this particular operation avoids the deadlock. BUT, it still seems like this is a bug. :)

I'll try follow policy and not report this on Jira until I'm told, but I'm hoping one of the devs could comment on this now. :)

Cheers,

Dag