If you're using the unit-of-work pattern properly, then you could handle the unique-key violation as an exception and then retry your unit-of-work. On the retry the row now exists and your code would (assuming no other problems) execute cleanly.
As an example: we've made this easy because we do our work by handling messages read from a queue. Each message read represents a unit-of-work. If it throws an exception, we put the message back on the queue to try again later. (There is some other infrastructure level stuff to detect poison messages, etc., but that's not important for this discussion). If you can't retry, you're going to have to implement some sort of lock somewhere. -- Joseph Daigle -- You received this message because you are subscribed to the Google Groups "nhusers" group. To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/TGgsuIR-F2UJ. 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.
