I am attempting to generate a new usage pattern to avoid this problem where a session is not kept open for longer than a single procedure that requires data access. The save button works just fine, but now my dirty checking on form close has become a problem.
On close, I create a new session, call .SaveOrUpdate with the primary object, and then check if it's dirty. It always is, even when the object has not changed from the database. I also tried .Lock(obj, ReadMode.Upgrade), and this always returns that it's not dirty, even when the object HAS changed from the database. There are many methods that all seem designed to handle these kinds of circumstances. Which ones should I be using? On Jan 24, 12:23 pm, Dietrich <[email protected]> wrote: > I've got a winforms production application that putting locks on three > tables in my SQL 2005 server almost all day long. I have many forms in > the system which use the same pattern, so what confuses me is that > only one specific form seems to be causing these locks. > > When the form is opened, it creates a session and loads the objects > that could be edited on that form. It keeps that session open for the > lifetime of the form and I use the session to perform a dirty check > when the form is closed to ask if the user wants to commit their > changes. > > The sessions are opened with a readuncommited isolation level. > > So question 1 - is this the right way to handle sessions? Should I use > one session to load the data for the form and another session to > commit the changes when they close a form? If so, how should I handle > dirty tracking? > > Question 2 - what specific kind of activity inside a session would > create table locks? Like I said, I use this same pattern on many > forms, but only one form seems to show this behavior. I'll be happy to > provide code, but this form hits a ton of code within my various > layers, and in the interest of brevity, I don't want to post a ton of > code that couldn't possibly have this impact. > > Thank you! -- 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.
