Community
Participate
Working Groups
Build Identifier: When calling JSFAppConfigManager.getInstance(IProject) there is a potential for deadlock if the JSFAppConfigManager is not yet initialized. the first call will cause the JSFAppConfigManagerFactory which is a ResourceSingletonObjectManager instenace to call createInstance while holding the monitor on the factory. Creating an instance of a JSFAppConfigManager requires a project scheduling rule to be acquired to read the web app model. If there is a second thread which already holds that project scheduling rule which tries to call JSFAppConfigManager.getInstance it will block on the monitor on JSFAppConfigManagerFactory and a deadlock is created. Reproducible: Sometimes
Build id: M20100909-0800
Created attachment 184082 [details] Proposed lock ordering patch. This proposed patch adds 2 protected methods to the internal base class of bath JSFAppConfigManagerFactory classes. There are default implementations to both methods so no other implementor will have to make changes. The two JSFAppConfigManagerFactory classes now implement these methods to allow checking of thread locking status and taking a project scheduling rule before taking a lock on the ResourceSingletonObjectManager instance monitor. This insures a consistent lock ordering. An IAdaptble object is produced as the result of the first new method and is passesd as a parameter to the second new method which allows the implementations to conditionally release a scheduling rule without having to maintain state between calls on their own which would be difficult as they are static instances.
Looks good, checked in. Thanks for the patch Andrew.
Created attachment 184157 [details] Proposed lock ordering patch Additional change required to avoid locking on JSFAppConfigManagerFactory.class monitor while acquiring rule.
Additional modification to avoid locking on JSFAppConfigManagerFactory.class monitor while acquiring rule has been committed.
