We have an Entity which has two fields (TargetType and TargetId). These are values which refer to a legacy data store and are immutable; the entity's constructor sets them. They are mapped as a composite natural ID, and the database has a UNIQUE constraint over them.
The usual method by which the entity is fetched is to use CreateQuery with something like "from Entity e where e.TargetId = :id and e.TargetType = :type", and get the unique result. Application logic then checks if the result is null. * If it is null (no Entity found), a different instance is requested from the same table via a different query, possibly updated (if found), and a new Entity created for the originally specified TargetId and TargetType values. Stuff is done to it and it is saved. * If it is not null, stuff is done to it and it is saved. The problem is that threads trying to save new Entity instances to the database often deadlock. The failing thread always gives up during the initial INSERT statement. Setting isolation level to ReadUncommitted makes the problem go away, but we'd rather avoid using that. Any higher isolation level causes the deadlocks. Establishing an exclusive table lock during the first SELECT would probably fix it, but NHibernate appears to provide no means of doing so except raw SQL. The basic intent of the operation is to fetch-or-create an Entity with the specified TargetType and TargetId values, and possibly do something to another Entity if it was a 'create'. Does NHibernate provide an atomic 'fetch-or-create'? Thanks, Alex -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
