Bill As I said on the dev list yesterday, that is not a complete solution.
Using IPT does avoid this particular deadlock, but because there is no EJB locking going on, you increase the risk of a deadlock in the database resulting in a transaction rollback. For example, consider 2 threads U1 and U2 which are both trying to update. U1 calls findByPrimaryKey, resulting in an S lock on the row U2 calls findByPrimaryKey, also resulting in an S lock U1 calls ejbLoad, using its S lock U2 calls ejbLoad, using its S lock U1 does an update, and blocks trying to convert to an X lock U2 does an update, resulting in a database deadlock and transaction rollback U1 completes This is different behaviour to that if the finder takes an U or X lock, where U2 would block in findByPrimaryKey until U1 completes. No deadlock, no rollback, but reduced concurrency. Also, consider the case where row-locking is true (e.g. in a cluster). IPT does not solve the problem then at all. Consider two threads R and W W calls findByPrimaryKey, resulting in an S lock R calls findByPrimaryKey, resulting in another S lock W calls ejbLoad and the SELECT FOR UPDATE blocks trying to convert the S lock to an X lock R calls ejbLoad, resulting in a database deadlock and aborted transaction Both of these scenarios show why write transactions need to indicate that intent when reading data. This is a well known issue, and is why SELECT FOR UPDATE and its equivalents were implemented by database vendors in the first place. Jeremy > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke > Sent: Sunday, June 22, 2003 3:12 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Deadlock issue with SQL Server and other > databases > > > All, if you're experiencing this problem, I'm pretty sure that > > Instance Per Transaction + SERIALIZABLE will solve your problems. > > Bill > > > -----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-user] 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 > > > > 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: > > > > * 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. > > > > 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. > > > > Jeremy > > > > /************************* > > * Jeremy Boynes > > * Partner > > * Core Developers Network > > *************************/ > > > > > > > > ------------------------------------------------------- > > 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-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > ------------------------------------------------------- > 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-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ------------------------------------------------------- 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-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
