Windows forms. On Jan 25, 10:51 pm, Fabio Maulo <[email protected]> wrote: > 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.
