Community
Participate
Working Groups
Scenario in GMF: - Outside client is executing a job on a worker thread. - GMF UI is still enabled while worker thread is executed - potentially causing updates to occur which will ask for a lock of the editing domain. Since transaction is executing on another thread, the UI will lock. - Notifications are received by GMF on the worker thread. - GMF needs to synchronously send the notifications to the UI thread to respect the transaction api contract using the Priveledged runnable. - Synch exec tries to obtain a lock, but UI has lock already --> DEADLOCK... GMF needs to be able to turn off display updates while the transaction is in progress. A hook at the beginning of the transaction and at the end of the transaction would satisfy this. The hook needs to be on the same thread as the transaction will be executed on. GMF can workaround this by dynamically querying the state of the transaction, but some cases might not allow updates to turn back on right away - if the write transaction didn't modify any resource and/or in rollback scenarios.
Can you provide an indication of how feasible this is and/or what the api impact for clients would be?
The post hook would be best after the postCommit call. So that the pre and post hooks wrap the entire execution of the transaction including the postCommit notifications.
For GMF's case, this can be implemented internally by extending the InternalTransactionalEditingDomain methods activate(InternalTransaction) and deactivate(InternalTransaction) to implement the required hooks. However, GMF won't be the only client that can benefit from generic notifications of starting and closing of transactions. I imagine a new listener interface (TransactionalEditingDomainListener) for domain-level state changes, which would include: - transactionAboutToStart - transactionStarted - transactionAboutToClose - transactionClosed - editingDomainDisposed Note that, unlike in some other listener APIs, the "about to" events would not be vetoable. Also, any number of "transactionAboutToStart" events could occur on different threads (concurrently) before a "transactionStarted", because about-to-start will be fired before a thread tries to get the lock. The transactionClosed event would occur after the transaction closed, either by commit or by rollback, regardless of whether any ResourceSetChangedEvents were sent to ResourceSetListeners. There would be no impact to clients as this would be entirely new API, except perhaps for any clients that implement the TransactionalEditingDomain interface without extending TransactionalEditingDomainImpl (which they really should not do). For this reason, it may be necessary to define an extension interface for the add/remove listener methods.
*** Bug 145880 has been marked as a duplicate of this bug. ***
As this is a new API and no longer blocks bug 145880 (which was resolved by a more appropriate fix), this is deferred to the next release (2.0 or 1.1, whichever comes first). It is undoubtedly still a useful API.
Est.: .5w
Committers can't contain this enhancement in their schedule; looking for help.
Postponing to the 1.2 release for consideration in the planning process.
Added a new TransactionalEditingDomainListener interface with call-backs: - transactionStarting - transactionInterrupted - transactionStarted - transactionClosing - transactionClosed Implementations of this listener interface are added to and removed from an editing domain using a new TransactionalEditingDomain.Lifecycle interface, which is an "optional adapter" available via TransactionUtil.getAdapter(...). As with all adapter interfaces, the Lifecycle protocol is optional. JUnit tests included.
Restore original target after milestones were deranged.
