Community
Participate
Working Groups
Currently the thread-safety of CDOView (and CDOTransaction!) is focused on proper synchronization between the InvalidationRunner thread in the CDOSession and *one* client thread per view. The current problems are: - A number of different locks are used, e.g. viewLock, stateLock, objectsLock --> deadlock potential - Not all places that need protection are properly guarded, e.g. tx.rollback() is not --> local data corruption potential Goal of this bugzilla: 1) Use only the view monitor 2) Use it in every non-private method of AbstractCDOView, CDOViewImpl, CDOTransactionImpl, CDOSavepointImpl, CDOStoreImpl, CDOStatemachine 3) Clarify whether it should be used in CDOObjectImpl and CDOObjectWrapper (would imply CDOLegacyAdapter, etc.)
This effort will also move the InvalidationRunner from CDOSessionImpl to CDOViewImpl (1 thread -> n threads). The session will still receive remote commitInfos and bring them in the right order (if needed) before passing them to all views. No additional thread will be involved anymore. A view will place the commitInfos from the session in a queue and let the InvalidationRunner handle it eventually. The overall timing will be slightly different: 1. Out-of-order commitInfos are queued, see CDOSessionImpl.invalidate() 2. When the right commitInfo is in the queue, see CDOSessionImpl.invalidateOrdered() : 2.1. the revisionManager is updated with the changeset, 2.2. the sessions's lastUpdateTime is set 2.3. CDOSessionInvalidationEvent is sent 2.4. commitInfo is passed to all views (new: views with unrelated branches are no longer excluded here!) 3. The view places the commitInfo in the invalidation queue, see CDOViewImpl.invalidate() 4. the views's InvalidationRunner processes the commitInfo, see CDOViewImpl.doInvalidate() 4.1. the view invalidates itself with the commitInfo's changeset *if the view's branch requires that* 4.1.1. CDOStateMachine is triggered for the changeset, conflicts detected 4.1.2. sendInvalidationNotifications() 4.1.3. handleConflicts() 4.1.4. sendDeltaNotifications() 4.1.5. fireAdaptersNotifiedEvent() 4.2. the view's lastUpdateTime is set *unconditionally* Three important consequences: a) The views of a session are no longer invalidated "atomically" altogether b) A view's lastUpdateTimeStamps is always updated and waitForUpdate() works more predictably
Created attachment 187359 [details] Patch v1 A patch until I'm sure I can fork branches in SVN :P
Committed revision 6894 to trunk
Created attachment 187379 [details] Patch v2 - attempt to execute XA transactin in parallel Idea: compute all the needed tx state *before* xa threads are forked. Does not fully work, yet. Keeping sequential execution for now...
Resolving for now.
*** Bug 326628 has been marked as a duplicate of this bug. ***
Committed revision 6966: - trunk/plugins/org.eclipse.emf.cdo - trunk/plugins/org.eclipse.emf.cdo.tests
Revision 6966 brought back the AbstractObjectConflictResolver.MergeLocalChangesPerFeature but deprecated it.
Available in R20110608-1407
