how is session per request not atomic? a request is atomic. if the scope of the NH session is the request, it's atomic by association. Have you experimented with 1. removing all explicit locks 2. removing versioning 3. removing both locks and versioning
if so what are the results? On Jan 25, 8:58 am, Murali R <[email protected]> wrote: > Hello, > We have a web application which runs on Nhibernate 1.2 on Service / > Repository pattern. > This application works well when a single user uses the application per > record. > However, when more than one user handles the application on the same record > (say update the same record), we are running into deadlock issues. > We have tried optimistic and pessimistic handling (LockMode)strategies. > The application now runs on SessionPerRequest model where in the transaction > gets activated on request beginning and commits all the dirty objects in the > session at the end of the request. This is not atomic in nature. > > The behaviours as as follows : > 1. Default lock mode : LockMode.None > 2. During Fetch By Id : LockMode.Read > 3. Transaction FlushMode : Auto > 4. All tables have version time stamp to regulate optimistic locking. > > As this application is large scale in nature, > can any one point to handle the following: > 1. Avoiding deadlocks on tables > 2. Handling nested transactions on Session within the same request (even > tough the flush happens only on the request end) > > Thanks in advance. > > -- > Regards, > Murali -- 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.
