Web or Win ? 2010/1/25 Dietrich <[email protected]>
> 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- Fabio Maulo -- 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.
