first of all, what you want (as i understand) is nested transactions, because today its a single update, and tomorow its more updates (what if your Profile entity has or will have associations?)
that is what you want, but what you need seems like simple logging. isn't your Work entity just a log? about exception handling, you can google Exception Handling Best Practice .NET to see all the different policies and how to handle them with exception handlers per policy On Tue, Sep 14, 2010 at 9:16 PM, Diego Mijelshon <[email protected]>wrote: > So you think an application can successfully recover from a RENAMED TABLE? > The best "handling" you can do in cases like that is logging the error (to > a writable folder that must be known beforehand), showing an adequate > messagebox to the user with the location of the log file and then, for the > love of G'd, CLOSING the application. > If you want something fancy, give the user an opportunity to fill an > automated error report on the fly (or do it automatically, whatever). > Continuing to run under such circumstances risks corrupting the data. > Nothing is more important than the data. > > Now, _business errors_ (you mentioned constraint violation should be > handled at the business/service level. And a good design will not require > exceptions. > If they do happen (because of concurrency), the original guideline still > applies: throw away the session, tell the user, reload the data, etc. > > Diego > > > > On Tue, Sep 14, 2010 at 16:01, Corey Coogan <[email protected]> wrote: > >> Actually, I never expect the application to fail, but regardless >> things can always go wrong. There are many reasons why an update to a >> table could fail. For example, constraint violation, network hiccup, >> table rename, etc. Letting an application fail gracefully is done by >> handling exceptions, no? Don't I need to catch the exception to get >> context on what happened so I know how to gracefully exit? >> >> Either way, the fact is that something can go wrong. If it does, I >> need to do something. Just different styles I suppose. >> >> Thanks, >> cc >> >> On Sep 14, 1:41 pm, Diego Mijelshon <[email protected]> wrote: >> > Corey, >> > >> > I disagree with the idea of "always trying to handle" the exceptions. >> > In most cases, the only sensible way of "handling" an unexpected >> exception >> > is crashing gracefully. >> > >> > Now, following on José's question: why are you expecting those updates >> to >> > fail? >> > What's the use case? Concurrency? >> > >> > Diego >> > >> > On Tue, Sep 14, 2010 at 15:35, Corey Coogan <[email protected]> >> wrote: >> > > @Diego >> > >> > > Thanks for the advice. I agree that it would be ideal to have designs >> > > that don't have to deal with exceptions, but that seems impractical in >> > > any DB operation. Not sure about you, but something can always go >> > > wrong here and I always try to handle my exceptions. I'm not really >> > > sure what you mean. How do you typically write code that doesn't have >> > > to deal with exceptions when interacting with a database? >> > >> > > On Sep 14, 1:24 pm, Diego Mijelshon <[email protected]> wrote: >> > > >http://nhforge.org/doc/nh/en/index.html#manipulatingdata-exceptions >> > > > "If the ISession throws an exception you should immediately rollback >> the >> > > > transaction, call ISession.Close() and discard the ISession >> instance. >> > > > Certain methods of ISession will *not* leave the session in a >> consistent >> > > > state." >> > >> > > > Lower level can be StatelessSession, for example. >> > >> > > > An alternative is changing your design so you DON'T get exceptions >> as >> > > part >> > > > of your regular workflow. >> > >> > > > Diego >> > >> > > > On Tue, Sep 14, 2010 at 15:20, Corey Coogan <[email protected]> >> wrote: >> > > > > Would you elaborate what you mean by lower level? You mean >> working >> > > > > directly against ADO? I'm not even sure how to do that with NH if >> > > > > that's what you are saying. >> > >> > > > > On Sep 14, 1:04 pm, Diego Mijelshon <[email protected]> >> wrote: >> > > > > > You can't use a Session to handle this scenario as-is. You'll >> have to >> > > go >> > > > > > lower-level. >> > >> > > > > > Diego >> > >> > > > > > On Tue, Sep 14, 2010 at 14:47, Corey Coogan < >> [email protected]> >> > > wrote: >> > > > > > > I have a scenario that I commonly run into. It's simple to do >> with >> > > a >> > > > > > > standard ADO Transaction, but not so much with NH (that I know >> of). >> > >> > > > > > > I have 2 tables to update. The first contains profile >> information >> > > > > > > (Profile) and the other (Work) contains records changes that >> need >> > > to >> > > > > > > be made and the status of those changes. For each update to >> the >> > > > > > > Profile table, there will be an update to the status on the >> Work >> > > > > > > table. >> > >> > > > > > > - If the update to the Profile table fails, I need to update >> the >> > > > > > > status on the Work table. >> > > > > > > - If the update to the Profile table succeeds, and the update >> to >> > > the >> > > > > > > Work table fails, I need to rollback the transaction. >> > >> > > > > > > The problem is that I don't know if the update to the Profile >> table >> > > > > > > failed until I commit the transaction. I tried to do a Flush >> on >> > > the >> > > > > > > Profile to catch the exception so I could write the status to >> the >> > > Work >> > > > > > > table, but then my Commit fails with the exception caused from >> the >> > > > > > > Profile update. >> > >> > > > > > > How can I handle this? In a typical ADO Transaction, my first >> call >> > > > > > > will throw, but I can catch and still update the other tables >> in >> > > the >> > > > > > > transaction. >> > >> > > > > > > Here's sort of what my code looks like - pretty standard. >> This is >> > > not >> > > > > > > my actual code, so please focus on the problem, not that I'm >> not >> > > > > > > disposing my transaction or closing my session ;) : >> > >> > > > > > > try >> > > > > > > { >> > > > > > > ITransaction trans = _session.BeginTransaction(); >> > >> > > > > > > var work = _repo.GetWork(); >> > > > > > > var profile = _repo.GetProfile(work.ProfileId); >> > >> > > > > > > try >> > > > > > > { >> > > > > > > profile.UpdateWithNewValues(work); >> > > > > > > _session.SaveOrUpdate(profile); >> > > > > > > _session.Flush(); >> > > > > > > work.Status = "Success"; >> > >> > > > > > > }catch{ >> > > > > > > work.Status = "Failure"; >> > > > > > > } >> > >> > > > > > > _session.SaveOrUpdate(work); >> > > > > > > trans.Commit(); >> > >> > > > > > > }catch{ >> > >> > > > > > > trans.Rollback(); >> > >> > > > > > > } >> > >> > > > > > > I realize that Flush() is not going to work, but I don't know >> how >> > > else >> > > > > > > to do this. >> > >> > > > > > > -- >> > > > > > > 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]<nhusers%[email protected]> >> <nhusers%[email protected]<nhusers%[email protected]> >> > >> > > <nhusers%[email protected]<nhusers%[email protected]> >> <nhusers%[email protected]<nhusers%[email protected]> >> > >> > >> > > > > <nhusers%[email protected]<nhusers%[email protected]> >> <nhusers%[email protected]<nhusers%[email protected]> >> > >> > > <nhusers%[email protected]<nhusers%[email protected]> >> <nhusers%[email protected]<nhusers%[email protected]> >> > >> > >> > > > > > > . >> > > > > > > For more options, visit this group at >> > > > > > >http://groups.google.com/group/nhusers?hl=en. >> > >> > > > > -- >> > > > > 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]<nhusers%[email protected]> >> <nhusers%[email protected]<nhusers%[email protected]> >> > >> > > <nhusers%[email protected]<nhusers%[email protected]> >> <nhusers%[email protected]<nhusers%[email protected]> >> > >> > >> > > > > . >> > > > > For more options, visit this group at >> > > > >http://groups.google.com/group/nhusers?hl=en. >> > >> > > -- >> > > 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]<nhusers%[email protected]> >> <nhusers%[email protected]<nhusers%[email protected]> >> > >> > > . >> > > For more options, visit this group at >> > >http://groups.google.com/group/nhusers?hl=en. >> >> -- >> 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]<nhusers%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> >> > -- > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- 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.
