Pardon me for my typo. the session is maintained at context level, however the transaction was at a request level(transaction begins on request begin and commits on request end)
We have mitigated most of the issues by having transaction scope locally around service calls say using(tx=new TransScope) try commit catch exception then tx.rollback this has avoided concurrency issues when more than one user tries to modify the same row concurrently. However, if more than one user tries to insert around 20 records into a table at the same time Say Cust1 places 10 orders and Cust 2 places 20 different orders at the same time, hence the attempt to place 30 inserts in order table deadlocks the order table We use LockMode.Read while fetching data and LockMode.None while saving the records. Any advice to avoid deadlock on tables because of multiple concurrent inserts ? Kindly help.. Thanks, Murali On Mon, Jan 25, 2010 at 8:06 PM, Jason Meckley <[email protected]>wrote: > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- 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.
