> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Jeremy Boynes > Sent: Saturday, June 21, 2003 12:17 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-dev] Deadlock issue with SQL Server and other databases > > > This bug indicates how a deadlock can occur between two threads > reading and > writing the same data: > http://sourceforge.net/tracker/index.php?func=detail&aid=758108&gr > oup_id=228 > 66&atid=376685 > > This is a hybrid deadlock where one thread gets blocked in the > database and > the other in the app server. As a result neither systems' > deadlock detection > works and the application hangs until the transaction times out. > > This can happen when: > * The database uses shared-read (S) locks on read and exclusive (X) locks > on writes. > * The database retains S locks for the duration of the transaction; for > example, if the database isolation level is raised to SERIALIZABLE > * The application reads data from the database before modifying it >
Are you sure this couldn't be avoided by using Instance Per Transaction + SERIALIZABLE + Commit C? > The row-locking option in CMP is meant to avoid such issues by > ensuring the > rows being read are locked so that updates can be performed > later. However, > this option only affects the query executed for ejbLoad, and not other > queries such as finders. > > I will be fixing this in 3.2 and HEAD by ensuring that the row-locking > option affects all queries executed by the CMP engine. This will cure the > deadlock scenario described in the bug, but may impact the application: > Now does your deadlock scenario only happen with Isolation level SERIALIZABLE? If so, I'm worried that if you expand row-locking to happen during finder queries, you'll break a lot of applications. If your deadlock scenario is only under SERIALIZABLE I suggest we investigate having metadata that can mark the transaction isolation level of the database connection so that we can avoid doing a lock during finder queries for READ_COMMITTED isolation levels and lower. It is my experience that the general use of JBoss and DBs is with READ_COMMITTED isolation. I'd hate to see concurrency suffer under READ_COMMITTED scenarios just to obtain completeness when the isolation level is SERIALIZABLE. Let's make sure that this doesn't happen. > * If two threads read data in different orders, then a deadlock can > occur at the database level; this is currently true at the EJB > level anyway. If this happens, the database's deadlock detection > may cause one query to be terminated (SQL Server does this) > resulting in rollback > > * Because all data is locked on read, concurrency will be reduced. > This is the expected behaviour for applications running at a > SERIALIZABLE isolation level. For those databases that support > it (e.g. SQL Server), I will try and make row-locking use update > locks rather than exclusive locks to allow reader threads to > proceed. However, without a mechanism to denote read-only > invocations, this may not have tangible benefit. > We do have a mechanism to denote read-only invocations, at least on the Entity Bean level. I would like a plan from you on what kind of metadata needs to flow within the context of an invocation. I have done some work on how contextual information should flow throughout the system with the AOP framework, but it probably needs to be expanded. A usecase from you would help in this arena. > I am posting this to the lists early as a heads-up of a change in > behaviour > as a consequence of fixing this bug. A change note will be posted when the > fix is committed. > Do not commit this change into the 3.2 branch until it has been fully documented by you within HEAD and fully reviewed by the community. We have to be very careful on how we apply fundamental changes to a maintainence release like 3.2.x. Other wise we may hinder our users from upgrading to a higher maintainence release because something as fundamental as locking has changed. Bill ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
