I am not sure if we are using the unit-of-work pattern "properly". We have a web application, and our DI container is wired up to allow one session per HTTP request. Thus, each session is used for all queries related to rendering a single response. If "if not exists insert" routine happens somewhere in the "middle" of the request handling, code-wise far from where the DI system would commit the session.
Will we need a different architecture where sessions are more local in order to handle the unique-key violation as an exception? /Jørn On Sep 15, 3:33 am, Joseph Daigle <[email protected]> wrote: > 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 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.
