Community
Participate
Working Groups
An adopter product is encountering the same type of EMF initialization deadlock as was reported in bug 315286 , except that this is occurring in the Java EE EMF models (whereas the previous one was in the j2ee EMF models).
Created attachment 184275 [details] Same deadlock fix as j2ee models
The patch here looks huge, but a lot is due to indentation. Simply put, instead of the initialization of any entry point causing everything to be initialized (which can deadlock if two initializations are waiting for each other), I am making the model initialization a directed initialization- each model element initializes all of the models it requires, and then it calls to J2EEInit(), which does a "bottom up" initialization of everything on a separate thread. Note that during the initialization, which requires being in a constructor, it is illegal to call wait(). Calling sleep() can cause one thread to wait, but it will not allow re-entrance into the constructor that is already in progress. Therefore, the full initialization should happen on its own thread, and still following the directed approach. (I chose the order that is in there because it will initialize things at the lowest level first, which reduces the risk of another thread waiting for initialization- if most of the required models of a particular EMF model are already initialized, its initialization should be quick and will be less likely to wait. The separate initialization is guarded to only happen once. I ran the entire J2EE JUnit bucket against this change.
approved
Committed to R3_2_maintenance and HEAD for WTP 3.2.3 and WTP 3.3
