CLR trigger - handling multiple inserts at the same time

Question

Hi
I've developed a CLR trigger which operates on inserts performed on a staging table. The trigger implements some business logic and then inserts or updates a record in a target table. Whether an insert or update is performed depends on whether
a record with the same ID already exists in the target (i.e. a select * from target where ID = 123).
This works fine in most scenarios, but occasionally I am getting duplicates in the target table and have noticed that this seems to occur when inserts on the staging table happen at exactly the same time (i.e. multiple inserts for the same ID at
the same time). In this situation duplicates are created in the target table because at the time of the inserts, no record with that ID exists in the target table (i.e. the select returns no records), therefore a new record is created for each.
Is there a known way to deal with this scenario? For example, would locking the target table on insert result in the subsequent selects against the target table waiting until the target table had been updated, therefore the select would return a record
for the given ID.
I didn't really want to lock the whole target table on insert, because there are potentially other users reading that table (selects) and these would also have to wait for the insert to complete.
I'd appreciate any thoughts on how to deal with this and avoid duplicates in the target table. I'm unable to change the way the data is coming in to the staging table, so my trigger code must deal with the above scenario.
Thanks in advance.
John

Answer 1

First if you do not want any duplicate values in a column (or combination of columns) you should add a constraint to ensure this is never possible. A
unique index
like this should do this trick.
CREATE UNIQUE NONCLUSTERED INDEX [IX_yourIndexName] ON [dbo].[YourTableName]
[yourColumn1] ASC,
-- add more columns that make the unique combination that you don't want repeated
You can then add a try/catch block in your trigger code, if you get an exception based on this index then the record was created by another executing instance of this trigger and in that case you should do an update (or not, not sure what the rest of your
logic is) in your catch block. This is the easiest solution and does not involve table locks. The only drawback is the first one to commit the insert will win and you have no guarantee which process or data set that will be. Also i have no idea how big the
table is, how frequently changes are made, and what the data type is so you should
keep this in mind when creating your index so you don't run into unexpected high index fragmentation which can lead to performance problems when executing updates and inserts.
You could also create a
named transaction with scope serializable around your insert/update block and execute your reads using a
NOLOCK hint
which should allow them to retrieve uncommitted writes and not create a long wait. The downside is is that the data might not be 100% accurate depending on if a transaction fails or not if there happens to be an update at the same time as a select but maybe
this is not a big deal to the calling code.
-Igor