Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » StrictCompoundCommand and TransactionalEditingDomain(StrictCompoundCommand and TransactionalEditingDomain)
StrictCompoundCommand and TransactionalEditingDomain [message #1403472] Thu, 24 July 2014 00:56 Go to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 223
Registered: July 2009
Senior Member
For many years we have extended the StrictCompoundCommand to create our own. Now we are switching some of those instances to operate with a transactional editing domain which results in errors as well documented in bugs like 207663.

What I see there are fixes on the edges, but not to the prepare() method of StrictCompoundCommand that does invoke execute outside of a transaction, or delegating to the editing domain command stack.

What is the plan with this?

Thanks
Alain
Re: StrictCompoundCommand and TransactionalEditingDomain [message #1403580 is a reply to message #1403472] Thu, 24 July 2014 13:42 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1195
Registered: July 2009
Location: Canada
Senior Member

Hi, Alain,

The principle on which the StrictCompoundCommand works isn't compatible
with the transactional editing domain, as you have observed. However,
you may be able to create your own variant (say,
TransactionalStrictCompoundCommand) that does what the
StrictCompoundCommand does, only in a transaction. I haven't tried
this, so I can't promise that you can make it work.

To test whether it is executable, the strict compound executes its
children and then undoes them. I call this the "trial". Just wrap
that up in a transaction and you should be OK. You'll need the
InternalTransactionalEditingDomain API to start a transaction in which
context to execute the compound's commands. Probably applying the
Transaction.OPTION_NO_VALIDATION to it would be useful both to save the
cost of running validation and to avoid any roll-back of the
transaction if you commit it. Also, the
Transaction.OPTION_NO_NOTIFICATIONS would ensure that listeners don't
hear about changes made and undone by the trial.

That said, I'm not sure how you should close this trial transaction:
your compound could do what StrictCompoundCommand does and undo all of
the children that were executed, in which case you could presumably
just commit the transaction because it should have no effect (and there
won't be any notifications, thanks to that option). Or, you might roll
it back just to be sure. If committing the transaction works, then you
might also use the Transaction.OPTION_NO_UNDO to avoid recording undo
information for roll-back. But, if your compound has any
RecordingCommands as children, they won't be able to undo because they
depend on the transaction recording the changes, so that wouldn't work.

Hmm, now that I mention it, I'm not sure how undoing RecordingCommands
would interact with roll-back of the trial transaction. You may just
have to commit it, after all, and be sure not to use the OPTION_NO_UNDO.

Whew, you're going to have a lot of JUnit test cases on your hands.
When it's all done, it would make a splendid contribution to the EMF
Transaction project! :-D

HTH,

Christian



On 2014-07-24 00:56:05 +0000, Alain Picard said:

> For many years we have extended the StrictCompoundCommand to create our
> own. Now we are switching some of those instances to operate with a
> transactional editing domain which results in errors as well documented
> in bugs like 207663.
>
> What I see there are fixes on the edges, but not to the prepare()
> method of StrictCompoundCommand that does invoke execute outside of a
> transaction, or delegating to the editing domain command stack.
>
> What is the plan with this?
>
> Thanks
> Alain
Re: StrictCompoundCommand and TransactionalEditingDomain [message #1403655 is a reply to message #1403580] Thu, 24 July 2014 23:16 Go to previous message
Alain Picard is currently offline Alain PicardFriend
Messages: 223
Registered: July 2009
Senior Member
Christian,

This makes a lot of sense and I'll try to run some tests and see what I can get going here.

Alain
Previous Topic:Transactions API: determine if running in a transaction
Next Topic:[XCORE] Loosing Memory/Memory Exhaustion
Goto Forum:
  


Current Time: Thu Aug 22 21:33:26 GMT 2019

Powered by FUDForum. Page generated in 0.01162 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top