Description Paul Fullbright 2011-04-18 15:44:49 EDT

I am having a problem with threadlock while using an extension of DataModelWizardPage in conjunction with an extension of ModifyFacetedProjectWizard.

When the wizard gets to performFinish(), it makes a call to the FacetedProjectWorkingCopy to commitChanges(..) which then also calls revertChanges(..).

This causes two things to happen in two different threads.

1 - My facet page config reacts to changes in the fpwc which causes it to query the LibraryInstallDelegate for its project facet version.  This occurs in the ModelContext thread, where the finish is occurring.

2 - The DataModelWizardPage reacts to changes in the config, and causes the page to validate.  Among the things being validated is the LibraryInstallDelegate, which is queried for its primary runtime, which locks with the query from 1.  This occurs in the main (UI) thread.


I am able to somewhat short-circuit this second validation, but this depends on the wizard page being one of the actual pages being shown in the wizard.  However, when a user changes the facets or versions in any way, a new facet page is created and the old one just hangs around, invisible.  (Should it be disposed at this time?)  I am unable to short-circuit the validation this page undergoes in any way that isn't hackish.


There are a variety of ways I can imagine addressing this problem.  One might involve disposing the orphan pages, but that would only solve part of the problem.  Another might involve moving the first process above to the UI thread, but none of the classes involved there are real "UI" classes, and so should probably be thread-ignorant, imo.  Of course, the solution I'm closest to implementing would be rolling my own facet install page, and leaving the data model impl alone.  I imagine I might run into some of the same problems, however.

I am open to suggestions...