Just to update this issue if anyone else is having the same problem: It turns out David E Jones-3 was right that my poor transactional programming in the custom import was causing deadlocks of other processes running at the same time. I followed OFBiz's example by creating an entity list of toBeStored and running a transaction only around the creation of that list and the createOrder function. Users say the system is running noticeably faster and with fewer-to-no deadlocks.
mayo wrote: > > I have been running OFBiz through normal usage tests for a client for > almost a month. Employees are working around 300 orders throughout an 8 > hour day with 2-3 warehouse users and 1-2 customer service users. I am > getting deadlocks throughout the day with the OFBiz 4.0 code that do not > have any custom modifications. > > I switched to SQLServerDriver, set lockTimeout to 3 minutes, set the > isolation level to ReadUncommitted, and enhanced the performance of the DB > server, but I still get locks and deadlocks. This wouldn't be a problem > because the user could just re-submit their request, but it becomes a > problem with submitting authorizations/captures/refunds to the payment > service. If the request is successful but writing the successful response > to the DB is deadlocked, the order is stuck--another request to the > payment service will fail. > > Has anyone had these problems with OFBiz 4.0 and SQLServer 2005? Also, > would it be possible to give a kick-start on integrating the OFBiz trunk > database pool logic into OFBiz 4.0? > -- View this message in context: http://www.nabble.com/MS-SQL-and-OFBiz%2C-database-locks-on-transactions-tp23225473p24224517.html Sent from the OFBiz - User mailing list archive at Nabble.com.
