search

eclipse-ee4j / glassfish

Eclipse GlassFish
https://eclipse-ee4j.github.io/glassfish/
386 stars 144 forks source link

Out-of-order database operations can lead to deadlock #349

Closed glassfishrobot closed 4 years ago

glassfishrobot commented 18 years ago

Given an entity A and a session bean that executes this code:

Query q = em.findNamedQuery("findAllA"); List l = q.getResultList(); Object[] arr = l.toArray(); Arrays.sort(arr); --> sort by Primary Key of A for (int i = 0; i < arr.length; i++) ((A)a[i]).setFoo(some value);

When the transaction of the session bean ends, a flurry of update statements will be committed to the database. The problem is that these update statements are not executed in order. Hence if two threads simultaneously execute this code, one of them will get a deadlock exception, despite the careful sorting of the operations in the application.

Environment

Operating System: All Platform: All

Affected Versions

[9.0pe]

glassfishrobot commented 6 years ago
glassfishrobot commented 18 years ago

@glassfishrobot Commented gyorke said: Although this is a theoretical issue that should be addressed no TopLink users have ever complained about TopLink causing deadlocks on the database.

It is very unlikely that a realworld application would consist of numerous threads all updating the exact same instances. If it were to occur those transactions would simply fail with a deadlock exception and the transactions would be retried by the application. As this should have low impact on almost all users I am altering the priority to have this issue fixed at a later time.

glassfishrobot commented 18 years ago

@glassfishrobot Commented mvatkina said: Reassigned

glassfishrobot commented 18 years ago

@glassfishrobot Commented sdo said: Unfortunately, it can have an impact on all users when the entities in question use pessimistic locking. If entities are obtained with queries using row-locking (a nativequery using "select for update" – presumably also a standard query with a query hint of LOCK_READ, except that issue 367 prevents me testing that), then if the operations are not processed in order by the entity manager code, that code itself will deadlock. As a result, rows in the database will remain locked forever and threads in the appserver will remain hung forever (compromising appserver reliability).

The appserver is hanging as two threads attempt to perform lock management on mutually-locked entities: Thread t@77: (state = BLOCKED)

Thread t@75: (state = BLOCKED)

I instrumented the CacheKey code and verified that each thread has locked the PK of one entity and is waiting to acquire the PK that the other thread has locked.

glassfishrobot commented 18 years ago

@glassfishrobot Commented gyorke said: The thread deadlock in the above post is a different issue. As such I am creating a new GlassFish issue : 410

glassfishrobot commented 12 years ago

@glassfishrobot Commented tmueller said: Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.

glassfishrobot commented 18 years ago

@glassfishrobot Commented Was assigned to tware

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-349

glassfishrobot commented 18 years ago

@glassfishrobot Commented Reported by sdo

smillidge commented 4 years ago

Closing as filed against a version of GlassFish not migrated to the Eclipse Foundation. If the issue is reproducible on 5.x or you still feel you need an enhancement for 5.x+ then request the issue reopened.