Home » Modeling » EMF » [EMF Transactions] Possible workarounds for IllegalStateExceptions from TransactionChangeRecorder?([EMF Transactions] Possible workarounds for IllegalStateExceptions from TransactionChangeRecorder?)
 [EMF Transactions] Possible workarounds for IllegalStateExceptions from TransactionChangeRecorder? [message #1706435] |
Wed, 26 August 2015 19:57  |
 Regent LArcheveque
Messages: 94
Registered: May 2010 |
Member |
|
|
Hi there,
We're currently working on a very large project (with hundreds of EMF meta-models) and we recently encountered a very serious problem with EMF Transactions while attempting to work with Sirius. Sirius leverages EMF Transactions and in particular, the TransactionalEditingDomain is used to implement transactional updates (undo, redo, etc.) for a given model in Sirius.
There are essentially two categories of updates which are performed on our models:
1) Updates that are driven by the user interacting with the model through the UI in Sirius, which naturally lends itself to commands and transactions.
2) Updates that are being made by background processes and communications, which should only be one-way state transitions; these should not be undone or reapplied again and as such, do not make sense to be done through the EditingDomain.
The core of the issue is that both updates are essentially happening to the same model at potentially the same time. As a result, the same TransactionalEditingDomain used to monitor and facilitate 1) is catching the changes made by 2). As a result, the respective TransactionChangeRecorder is throwing IllegalStateExceptions whenever 2) model updates occur.
It's important to note that there are WAY too many updates (probably several thousand) of the 2) variety of even consider refactoring and implementing a command / transaction for each of them. Sirius (and other tools like it) is important but was simply meant to streamline and improve the UI of an already working system.
Furthermore, Sirius uses the EMF Transactions all over the place in their code; trying to simply remove them from Sirius or hack it to get things to work is not a viable option either as it would remove a lot of the functionality which is needed for 1) updates.
This brings us to the following question: What, if anything, can we do to work around or resolve this situation, in regards to EMF Transactions? Is there something you can think of that could work for our situation?
I'd really appreciate any help and guidance that you can offer.
Thanks you very much for your time and I look forward to reading your reply.
Regent 
|
|
|
| Re: [EMF Transactions] Possible workarounds for IllegalStateExceptions from TransactionChangeRecorde [message #1706547 is a reply to message #1706435] |
Thu, 27 August 2015 15:30  |
|
Hi, Regent,
There really isn't any work-around. At least, there's not intended to be.
The thing is, that one of the purposes of the
TransactionalEditingDomain is to provide for safe access to its model
resources in a multi-threaded application. It essentially provides a
global lock on the resource set, which can be cooperatively shared by
threads (both for reading and for writing) in a strictly
serial/synchronous fashion. You simply can't have some threads using
these synchronization mechanisms and others not using them.
It seems to me that the changes that your background threads (number 2)
are doing will corrupt the undo/redo history of any changes made by
commands in the Sirius UI (number 1). If these background threads
change the same objects as are changed by commands on the undo stack,
then those commands can no longer safely be undone because they will
try to reverse changes that don't make sense for the current state of
the objects that they would change. All changes in a
TransactionalEditingDomain are expected to be done in serial order,
usually in commands on the undo stack, for this reason. The exceptions
(for which "unprotected transactions" are provided in the API) are
changes that for whatever reason are known a priori not to be able to
have any side-effects on previous changes, usually because the objects
in question had never been changed or even observed previously, or
because they are entirely distinct resources that aren't connected with
anything else. Of course, in that case, they may as well be in a
different editing domain and resource set.
Does that make sense?
HTH,
Christian
On 2015-08-26 19:58:01 +0000, Regent LArcheveque said:
> Hi there,
> We're currently working on a very large project (with hundreds of EMF
> meta-models) and we recently encountered a very serious problem with
> EMF Transactions while attempting to work with Sirius. Sirius
> leverages EMF Transactions and in particular, the
> TransactionalEditingDomain is used to implement transactional updates
> (undo, redo, etc.) for a given model in Sirius.
>
> There are essentially two categories of updates which are performed on
> our models:
>
> 1) Updates that are driven by the user interacting with the model
> through the UI in Sirius, which naturally lends itself to commands and
> transactions.
>
> 2) Updates that are being made by background processes and
> communications, which should only be one-way state transitions; these
> should not be undone or reapplied again and as such, do not make sense
> to be done through the EditingDomain.
>
> The core of the issue is that both updates are essentially happening to
> the same model at potentially the same time. As a result, the same
> TransactionalEditingDomain used to monitor and facilitate 1) is
> catching the changes made by 2). As a result, the respective
> TransactionChangeRecorder is throwing IllegalStateExceptions whenever
> 2) model updates occur.
>
> It's important to note that there are WAY too many updates (probably
> several thousand) of the 2) variety of even consider refactoring and
> implementing a command / transaction for each of them. Sirius (and
> other tools like it) is important but was simply meant to streamline
> and improve the UI of an already working system.
> Furthermore, Sirius uses the EMF Transactions all over the place in
> their code; trying to simply remove them from Sirius or hack it to get
> things to work is not a viable option either as it would remove a lot
> of the functionality which is needed for 1) updates.
>
> This brings us to the following question: What, if anything, can we do
> to work around or resolve this situation, in regards to EMF
> Transactions? Is there something you can think of that could work for
> our situation?
>
> I'd really appreciate any help and guidance that you can offer.
>
> Thanks you very much for your time and I look forward to reading your reply.
>
> Regent ;)
|
|
|
| Re: [EMF Transactions] Possible workarounds for IllegalStateExceptions from TransactionChangeRecorde [message #1706892 is a reply to message #1706547] |
Mon, 31 August 2015 15:53 |
Regent LArcheveque
Messages: 94
Registered: May 2010 |
Member |
|
|
Thanks Christian for the feedback. It is appreciated.
We understand the TransactionalEditingDomain ensures integrity for multi-threaded applications while the default EMF Adapter Editing Domain is single threaded. We created EMF meta-models to interface with hardware such as rover, robotic arm, drill, camera. These meta-models only use the EMF foundation (.core, .edit, .editor). Under the hood, the generated classes make use of eOperations and of setters to change object states. At the same time, Editing domain is used to let the user to specify sequences of eOperations to execute. In that case, the command stack is used and let the user to modify (undo, redo, copy/paste) those sequences of commands. EMF reflection is used as well to provide object states via Property Views and label providers. A single Resource Set is used for the moment and it works properly well for the moment with the default EMF Adapter Editing Domain because, the number of data producers / consumers is controlled and prevent collision. However that prevents us to exploit the Transactional Editing Domain. We could dissociate resources that are driven with or without a editing domain. But that still have to consider that a single Resource Set is used. I try to find out an architecture pattern that could allow us to exploit existing EMF low drivers and EMF Transactions.
|
|
|
Goto Forum:
Current Time: Thu Apr 18 03:50:44 GMT 2024
Powered by FUDForum. Page generated in 0.01650 seconds |
] 
Search
Help
Register
Login
Home
