[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[eclipse.org-architecture-council] [Bug 245573] Deadlock with JPA Validator
|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=245573
Product/Component: Dali JPA Tools / Framework
John Arthorne <john_arthorne@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eclipse.org-architecture-
| |council@xxxxxxxxxxx
--- Comment #12 from John Arthorne <john_arthorne@xxxxxxxxxx> 2008-09-09 11:26:19 -0400 ---
It is suspicious to me that Worker-5 is performing workspace changes from
within a bundle activator (org/eclipse/jpt/db/JptDbPlugin.start). This is
already deadlock prone because bundle activation occurs while the classloader
lock is held. Also, since this can be initiated simply by having a reference to
a class in that plugin, it causes potentially locking code to run at
unpredictable times for clients. I would suggest pushing that bundle's
long-running activation work into a background job.
Another fix would be to change JpaModelManager to perform its resource change
event processing asynchronously rather than directly within the resource change
event callback (the synchronizeFiles method). Again because this results in
insertion of locking behavior onto any client performing workspace changes,
acquiring locks within a resource change callback is potentially dangerous
(unless you are certain you never call out to foreign code while holding that
lock, and David mentions). A common pattern here is to process the delta within
the resource change event to gather the useful information, and then fork off a
job to perform any locking/long-running update work (as described in
http://www.eclipse.org/articles/Article-Resource-deltas/resource-deltas.html#1d).
--
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
