Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 145877

Summary:	Need pre / post hooks for Transaction execution
Product:	[Modeling] EMF Services	Reporter:	Steven R. Shaw <steveshaw>
Component:	Transaction	Assignee:	Christian Damus <give.a.damus>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P2	CC:	schafe
Version:	unspecified	Keywords:	api, noteworthy, plan
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	Client Control

Description Steven R. Shaw

2006-06-07 17:03:34 EDT

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.

Comment 1 Steven R. Shaw

2006-06-08 09:33:22 EDT

Can you provide an indication of how feasible this is and/or what the api impact for clients would be?

Comment 2 Steven R. Shaw

2006-06-08 09:48:05 EDT

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.

Comment 3 Christian Damus

2006-06-08 10:18:13 EDT

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.

Comment 4 Steven R. Shaw

2006-06-12 11:48:31 EDT

*** Bug 145880 has been marked as a duplicate of this bug. ***

Comment 5 Christian Damus

2006-06-20 15:53:52 EDT

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.

Comment 6 Christian Damus

2006-11-17 15:58:39 EST

Est.: .5w

Comment 7 Christian Damus

2006-12-19 10:01:31 EST

Committers can't contain this enhancement in their schedule; looking for help.

Comment 8 Christian Damus

2007-05-10 10:16:55 EDT

Postponing to the 1.2 release for consideration in the planning process.

Comment 9 Christian Damus

2008-09-20 17:30:27 EDT

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.

Comment 10 Christian Damus

2008-11-24 13:09:38 EST

Restore original target after milestones were deranged.