Home » Modeling » EMF » Transactions API: determine if running in a transaction
| Transactions API: determine if running in a transaction [message #1403179] |
Tue, 22 July 2014 08:23  |
 Erdal Karaca
Messages: 854
Registered: July 2009 |
Senior Member |
|
|
Short question: Is it possible to determine if code is running inside a transaction, for example, within a RecordingCommand?
MyModel modelObject =...;
RecordinCommand rc = new RecordingCommand() {
run() {
publicAPIMethod(modelObject);
}
}
publicAPIMethod(EObject eObject) {
if(inTransaction()) {
eObject.setStringAttribute("newString");
} else {
SetCommand sc = new SetComand(editingDomain, eObject, feature, "newString");
executeCommand(sc);
}
}
Background: We have a "matured" thin API layer (facade) that provides access/modification to/of an ecore model (by hiding the internals of the transactions API). Sometimes, the facade is not sufficient to cover complex scenarios, so the logic has to be done within a recording command. Within the recording command, we would need to use the facade itself, but that is executing commands on the command stack which would lead to nested transactions. The facade implementation could be extended to not execute commands on the command stack, but instead modify the model directly. For this, we would need to determine when we are within a running transaction.
Thanks!
|
|
| |
| Re: Transactions API: determine if running in a transaction [message #1403387 is a reply to message #1403278] |
Wed, 23 July 2014 11:38  |
Erdal Karaca
Messages: 854
Registered: July 2009 |
Senior Member |
|
|
Is the nested transactions support of the Transactions API expected to work "reliably" (for example, anything done in a recording command can be executed and undone, so I think it works "reliable").
AFAIK, other frameowrks do not support nested transactions (for example, CDO or Hibernate). So, maybe that is something to acoid or would you say it is "mature" enough to use and/or is it a officially supported feature?
Felix Dorner wrote on Tue, 22 July 2014 10:58On 22/07/2014 10:23, Erdal Karaca wrote:
> Short question: Is it possible to determine if code is running inside a
> transaction, for example, within a RecordingCommand?
>
You can use InternalTransactionalEditingDomain.getActiveTransaction()
>
> Background: We have a "matured" thin API layer (facade) that provides
> access/modification to/of an ecore model (by hiding the internals of the
> transactions API). Sometimes, the facade is not sufficient to cover
> complex scenarios, so the logic has to be done within a recording
> command. Within the recording command, we would need to use the facade
> itself, but that is executing commands on the command stack which would
> lead to nested transactions.
What's the problem with nested transactions?
Felix
|
|
| |
| Re: Transactions API: determine if running in a transaction [message #1403391 is a reply to message #1403387] |
Wed, 23 July 2014 11:56 |
|
Hi, Erdal,
Nested transactions were a primary design requirement from the outset,
so yes, they are fully supported (and tested in the field) and seem to
work reliably. Nested transactions even support incorporation of
undo/redo of non-EMF operations (commands that update application state
that isn't the EMF modeled data). The Luna release of Papyrus actually
makes heavy use of transaction nesting via a nesting command-stack,
especially in the modal property dialogs.
Nested transactions can be rolled back or committed like any other.
Committing a nested transaction fires trigger listeners, but do not
perform validation, nor do they fire post-commit listeners. These
actions are only performed at the commit of a top-level transaction
because nested transactions are not required to maintain data integrity
(there's a larger transaction context) and they can still be rolled
back, even after they have been committed, by roll-back of a nesting
transaction (at any depth).
EMF Transactions don't share much of the semantics of transactions in
other systems such as databases, where one has the notion of
transaction isolation, durability, etc. It's a fairly light-weight
editing layer on top of the regular EMF editing domain, so I wouldn't
expect many of the technical problems of transaction nesting in other
contexts to apply here.
HTH,
Christian
On 2014-07-23 11:38:26 +0000, Erdal Karaca said:
> Is the nested transactions support of the Transactions API expected to
> work "reliably" (for example, anything done in a recording command can
> be executed and undone, so I think it works "reliable").
>
> AFAIK, other frameowrks do not support nested transactions (for
> example, CDO or Hibernate). So, maybe that is something to acoid or
> would you say it is "mature" enough to use and/or is it a officially
> supported feature?
>
> Felix Dorner wrote on Tue, 22 July 2014 10:58
>> On 22/07/2014 10:23, Erdal Karaca wrote:
>>> Short question: Is it possible to determine if code is running inside a
>>> transaction, for example, within a RecordingCommand?
>>>
>>
>> You can use InternalTransactionalEditingDomain.getActiveTransaction()
>>
>>>
>>> Background: We have a "matured" thin API layer (facade) that provides
>>> access/modification to/of an ecore model (by hiding the internals of the
>>> transactions API). Sometimes, the facade is not sufficient to cover
>>> complex scenarios, so the logic has to be done within a recording
>>> command. Within the recording command, we would need to use the facade
>>> itself, but that is executing commands on the command stack which would
>>> lead to nested transactions.
>>
>> What's the problem with nested transactions?
>>
>> Felix
|
|
|
| Re: Transactions API: determine if running in a transaction [message #1403398 is a reply to message #1403391] |
Wed, 23 July 2014 12:30 |
Erdal Karaca
Messages: 854
Registered: July 2009 |
Senior Member |
|
|
Thanks Christian and Felix,
That has helped to go for the nested transactions feature.
Christian W. Damus wrote on Wed, 23 July 2014 13:56Hi, Erdal,
Nested transactions were a primary design requirement from the outset,
so yes, they are fully supported (and tested in the field) and seem to
work reliably. Nested transactions even support incorporation of
undo/redo of non-EMF operations (commands that update application state
that isn't the EMF modeled data). The Luna release of Papyrus actually
makes heavy use of transaction nesting via a nesting command-stack,
especially in the modal property dialogs.
Nested transactions can be rolled back or committed like any other.
Committing a nested transaction fires trigger listeners, but do not
perform validation, nor do they fire post-commit listeners. These
actions are only performed at the commit of a top-level transaction
because nested transactions are not required to maintain data integrity
(there's a larger transaction context) and they can still be rolled
back, even after they have been committed, by roll-back of a nesting
transaction (at any depth).
EMF Transactions don't share much of the semantics of transactions in
other systems such as databases, where one has the notion of
transaction isolation, durability, etc. It's a fairly light-weight
editing layer on top of the regular EMF editing domain, so I wouldn't
expect many of the technical problems of transaction nesting in other
contexts to apply here.
HTH,
Christian
On 2014-07-23 11:38:26 +0000, Erdal Karaca said:
> Is the nested transactions support of the Transactions API expected to
> work "reliably" (for example, anything done in a recording command can
> be executed and undone, so I think it works "reliable").
>
> AFAIK, other frameowrks do not support nested transactions (for
> example, CDO or Hibernate). So, maybe that is something to acoid or
> would you say it is "mature" enough to use and/or is it a officially
> supported feature?
>
> Felix Dorner wrote on Tue, 22 July 2014 10:58
>> On 22/07/2014 10:23, Erdal Karaca wrote:
>>> Short question: Is it possible to determine if code is running inside a
>>> transaction, for example, within a RecordingCommand?
>>>
>>
>> You can use InternalTransactionalEditingDomain.getActiveTransaction()
>>
>>>
>>> Background: We have a "matured" thin API layer (facade) that provides
>>> access/modification to/of an ecore model (by hiding the internals of the
>>> transactions API). Sometimes, the facade is not sufficient to cover
>>> complex scenarios, so the logic has to be done within a recording
>>> command. Within the recording command, we would need to use the facade
>>> itself, but that is executing commands on the command stack which would
>>> lead to nested transactions.
>>
>> What's the problem with nested transactions?
>>
>> Felix
|
|
|
| Re: Transactions API: determine if running in a transaction [message #1403401 is a reply to message #1403391] |
Wed, 23 July 2014 12:35 |
Felix Dorner
Messages: 295
Registered: March 2012 |
Senior Member |
|
|
On 23/07/2014 13:56, Christian W. Damus wrote:
> Hi, Erdal,
>
> Nested transactions were a primary design requirement from the outset,
> so yes, they are fully supported (and tested in the field) and seem to
> work reliably. Nested transactions even support incorporation of
> undo/redo of non-EMF operations (commands that update application state
> that isn't the EMF modeled data). The Luna release of Papyrus actually
> makes heavy use of transaction nesting via a nesting command-stack,
> especially in the modal property dialogs.
>
> Nested transactions can be rolled back or committed like any other.
> Committing a nested transaction fires trigger listeners, but do not
> perform validation, nor do they fire post-commit listeners. These
> actions are only performed at the commit of a top-level transaction
> because nested transactions are not required to maintain data integrity
> (there's a larger transaction context) and they can still be rolled
> back, even after they have been committed, by roll-back of a nesting
> transaction (at any depth).
I think the confusion arises when thinking in terms of executing
commands on a transactional command stack, which are the principal mean
to create transactions.
So If I execute a command A on the stack that itself executes another
one B on the same stack, this would create a nested transaction and
might wreak hazard when looking at undo semantics:
The command stack would have A, B<--top, correct?
So if I undo B, and then undo A, wouldn't the changes made by B be
undone twice because A also recorded the changes made by B?
And also: If A had continued to change stuff after B completed, undoing
B may already break stuff because changes were made after it completed,
so the context in which it is undone has changed?
You mention nested command stacks in papyrus. Maybe you can give us
something clickable to see some code action? :)
Thanks,
Felix
> EMF Transactions don't share much of the semantics of transactions in
> other systems such as databases, where one has the notion of transaction
> isolation, durability, etc. It's a fairly light-weight editing layer on
> top of the regular EMF editing domain, so I wouldn't expect many of the
> technical problems of transaction nesting in other contexts to apply here.
>
> HTH,
>
> Christian
>
>
> On 2014-07-23 11:38:26 +0000, Erdal Karaca said:
>
>> Is the nested transactions support of the Transactions API expected to
>> work "reliably" (for example, anything done in a recording command can
>> be executed and undone, so I think it works "reliable").
>>
>> AFAIK, other frameowrks do not support nested transactions (for
>> example, CDO or Hibernate). So, maybe that is something to acoid or
>> would you say it is "mature" enough to use and/or is it a officially
>> supported feature?
>>
>> Felix Dorner wrote on Tue, 22 July 2014 10:58
>>> On 22/07/2014 10:23, Erdal Karaca wrote:
>>>> Short question: Is it possible to determine if code is running inside a
>>>> transaction, for example, within a RecordingCommand?
>>>>
>>>
>>> You can use InternalTransactionalEditingDomain.getActiveTransaction()
>>>
>>>>
>>>> Background: We have a "matured" thin API layer (facade) that provides
>>>> access/modification to/of an ecore model (by hiding the internals of
>>>> the
>>>> transactions API). Sometimes, the facade is not sufficient to cover
>>>> complex scenarios, so the logic has to be done within a recording
>>>> command. Within the recording command, we would need to use the facade
>>>> itself, but that is executing commands on the command stack which would
>>>> lead to nested transactions.
>>>
>>> What's the problem with nested transactions?
>>>
>>> Felix
>
>
|
|
|
| Re: Transactions API: determine if running in a transaction [message #1403403 is a reply to message #1403401] |
Wed, 23 July 2014 12:52 |
Felix Dorner
Messages: 295
Registered: March 2012 |
Senior Member |
|
|
On 23/07/2014 14:35, Felix Dorner wrote:
> So If I execute a command A on the stack that itself executes another
> one B on the same stack, this would create a nested transaction and
> might wreak hazard when looking at undo semantics:
>
> The command stack would have A, B<--top, correct?
>
> So if I undo B, and then undo A, wouldn't the changes made by B be
> undone twice because A also recorded the changes made by B?
>
> And also: If A had continued to change stuff after B completed, undoing
> B may already break stuff because changes were made after it completed,
> so the context in which it is undone has changed?
Hmm, well but this problematic isn't really related to transactions. the
same thing applies to "normal" emf commands and a basic command stack..
|
|
|
| Re: Transactions API: determine if running in a transaction [message #1403406 is a reply to message #1403401] |
Wed, 23 July 2014 13:11 |
|
Hi, Felix,
See some replies in-line, below.
cW
On 2014-07-23 12:35:11 +0000, Felix Dorner said:
>
> I think the confusion arises when thinking in terms of executing
> commands on a transactional command stack, which are the principal mean
> to create transactions.
Right, that's a good point. There are, of course, also read-only
transactions, which will more commonly nest than read/write.
> So If I execute a command A on the stack that itself executes another
> one B on the same stack, this would create a nested transaction and
> might wreak hazard when looking at undo semantics:
Indeed.
> The command stack would have A, B<--top, correct?
>
> So if I undo B, and then undo A, wouldn't the changes made by B be
> undone twice because A also recorded the changes made by B?
It depends. The undo of B may actually not have any effect, if it had
transaction nesting disabled (it's an option in the command/operation
API somewhere). Nesting *commands* is definitely something to be
avoided, unless you're using a stack designed to support it.
> And also: If A had continued to change stuff after B completed, undoing
> B may already break stuff because changes were made after it completed,
> so the context in which it is undone has changed?
Yep.
> You mention nested command stacks in papyrus. Maybe you can give us
> something clickable to see some code action? :)
Sure thing:
http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/gmfdiag/org.eclipse.papyrus.infra.gmfdiag.commands/src/org/eclipse/papyrus/commands/NestingNotifyingWorkspaceCommandStack.java
This addresses the problems you outlined by ensuring that nested
commands are executed but not presented in the undo history. Only the
top-level command is added to the history, and it captures the entirety
of the nested changes.
>
> Thanks,
> Felix
>
>
>
>> EMF Transactions don't share much of the semantics of transactions in
>> other systems such as databases, where one has the notion of transaction
>> isolation, durability, etc. It's a fairly light-weight editing layer on
>> top of the regular EMF editing domain, so I wouldn't expect many of the
>> technical problems of transaction nesting in other contexts to apply here.
>>
>> HTH,
>>
>> Christian
>>
>>
>> On 2014-07-23 11:38:26 +0000, Erdal Karaca said:
>>
>>> Is the nested transactions support of the Transactions API expected to
>>> work "reliably" (for example, anything done in a recording command can
>>> be executed and undone, so I think it works "reliable").
>>>
>>> AFAIK, other frameowrks do not support nested transactions (for
>>> example, CDO or Hibernate). So, maybe that is something to acoid or
>>> would you say it is "mature" enough to use and/or is it a officially
>>> supported feature?
>>>
>>> Felix Dorner wrote on Tue, 22 July 2014 10:58
>>>> On 22/07/2014 10:23, Erdal Karaca wrote:
>>>>> Short question: Is it possible to determine if code is running inside a
>>>>> transaction, for example, within a RecordingCommand?
>>>>>
>>>>
>>>> You can use InternalTransactionalEditingDomain.getActiveTransaction()
>>>>
>>>>>
>>>>> Background: We have a "matured" thin API layer (facade) that provides
>>>>> access/modification to/of an ecore model (by hiding the internals of
>>>>> the
>>>>> transactions API). Sometimes, the facade is not sufficient to cover
>>>>> complex scenarios, so the logic has to be done within a recording
>>>>> command. Within the recording command, we would need to use the facade
>>>>> itself, but that is executing commands on the command stack which would
>>>>> lead to nested transactions.
>>>>
>>>> What's the problem with nested transactions?
>>>>
>>>> Felix
|
|
|
| Re: Transactions API: determine if running in a transaction [message #1403411 is a reply to message #1403406] |
Wed, 23 July 2014 14:08 |
Erdal Karaca
Messages: 854
Registered: July 2009 |
Senior Member |
|
|
Thanks for the additional hints:
When executing a command A which itself executes a (nested) command B, the undo history does not show up to first undo B, then A, instead I can undo A (which properly does undo the changes of B, first).
We are using the platform's (Eclipse) undo history API and I am not aware of any stack implementations that we intentionally use that manages nested commands.
So, is this (management of nested commands) a feature provided by the platform undo history?
Christian W. Damus wrote on Wed, 23 July 2014 15:11Hi, Felix,
See some replies in-line, below.
cW
On 2014-07-23 12:35:11 +0000, Felix Dorner said:
>
> I think the confusion arises when thinking in terms of executing
> commands on a transactional command stack, which are the principal mean
> to create transactions.
Right, that's a good point. There are, of course, also read-only
transactions, which will more commonly nest than read/write.
> So If I execute a command A on the stack that itself executes another
> one B on the same stack, this would create a nested transaction and
> might wreak hazard when looking at undo semantics:
Indeed.
> The command stack would have A, B<--top, correct?
>
> So if I undo B, and then undo A, wouldn't the changes made by B be
> undone twice because A also recorded the changes made by B?
It depends. The undo of B may actually not have any effect, if it had
transaction nesting disabled (it's an option in the command/operation
API somewhere). Nesting *commands* is definitely something to be
avoided, unless you're using a stack designed to support it.
> And also: If A had continued to change stuff after B completed, undoing
> B may already break stuff because changes were made after it completed,
> so the context in which it is undone has changed?
Yep.
> You mention nested command stacks in papyrus. Maybe you can give us
> something clickable to see some code action? 
Sure thing:
http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/gmfdiag/org.eclipse.papyrus.infra.gmfdiag.commands/src/org/eclipse/papyrus/commands/NestingNotifyingWorkspaceCommandStack.java
This addresses the problems you outlined by ensuring that nested
commands are executed but not presented in the undo history. Only the
top-level command is added to the history, and it captures the entirety
of the nested changes.
>
> Thanks,
> Felix
>
>
>
>> EMF Transactions don't share much of the semantics of transactions in
>> other systems such as databases, where one has the notion of transaction
>> isolation, durability, etc. It's a fairly light-weight editing layer on
>> top of the regular EMF editing domain, so I wouldn't expect many of the
>> technical problems of transaction nesting in other contexts to apply here.
>>
>> HTH,
>>
>> Christian
>>
>>
>> On 2014-07-23 11:38:26 +0000, Erdal Karaca said:
>>
>>> Is the nested transactions support of the Transactions API expected to
>>> work "reliably" (for example, anything done in a recording command can
>>> be executed and undone, so I think it works "reliable").
>>>
>>> AFAIK, other frameowrks do not support nested transactions (for
>>> example, CDO or Hibernate). So, maybe that is something to acoid or
>>> would you say it is "mature" enough to use and/or is it a officially
>>> supported feature?
>>>
>>> Felix Dorner wrote on Tue, 22 July 2014 10:58
>>>> On 22/07/2014 10:23, Erdal Karaca wrote:
>>>>> Short question: Is it possible to determine if code is running inside a
>>>>> transaction, for example, within a RecordingCommand?
>>>>>
>>>>
>>>> You can use InternalTransactionalEditingDomain.getActiveTransaction()
>>>>
>>>>>
>>>>> Background: We have a "matured" thin API layer (facade) that provides
>>>>> access/modification to/of an ecore model (by hiding the internals of
>>>>> the
>>>>> transactions API). Sometimes, the facade is not sufficient to cover
>>>>> complex scenarios, so the logic has to be done within a recording
>>>>> command. Within the recording command, we would need to use the facade
>>>>> itself, but that is executing commands on the command stack which would
>>>>> lead to nested transactions.
>>>>
>>>> What's the problem with nested transactions?
>>>>
>>>> Felix
|
|
|
| Re: Transactions API: determine if running in a transaction [message #1403582 is a reply to message #1403411] |
Thu, 24 July 2014 13:49 |
|
Hi, Erdal,
From my reading of the DefaultOperationHistory source, it doesn't
support nesting unless it has a composite "open", which is something
that must be done explicitly. AFAIK, the transactional editing domain
doesn't open composites on the history. This is something that your
application must be doing, otherwise you should see B in the undo
history.
cW
On 2014-07-23 14:08:15 +0000, Erdal Karaca said:
> Thanks for the additional hints:
>
> When executing a command A which itself executes a (nested) command B,
> the undo history does not show up to first undo B, then A, instead I
> can undo A (which properly does undo the changes of B, first).
>
> We are using the platform's (Eclipse) undo history API and I am not
> aware of any stack implementations that we intentionally use that
> manages nested commands.
> So, is this (management of nested commands) a feature provided by the
> platform undo history?
>
> Christian W. Damus wrote on Wed, 23 July 2014 15:11
>> Hi, Felix,
>>
>> See some replies in-line, below.
>>
>> cW
>>
>> On 2014-07-23 12:35:11 +0000, Felix Dorner said:
>>
>>>
>>> I think the confusion arises when thinking in terms of executing
>>> commands on a transactional command stack, which are the principal mean
>>> to create transactions.
>>
>> Right, that's a good point. There are, of course, also read-only
>> transactions, which will more commonly nest than read/write.
>>
>>
>>> So If I execute a command A on the stack that itself executes another
>>> one B on the same stack, this would create a nested transaction and
>>> might wreak hazard when looking at undo semantics:
>>
>> Indeed.
>>
>>
>>> The command stack would have A, B<--top, correct?
>>>
>>> So if I undo B, and then undo A, wouldn't the changes made by B be
>>> undone twice because A also recorded the changes made by B?
>>
>> It depends. The undo of B may actually not have any effect, if it had
>> transaction nesting disabled (it's an option in the command/operation
>> API somewhere). Nesting *commands* is definitely something to be
>> avoided, unless you're using a stack designed to support it.
>>
>>
>>> And also: If A had continued to change stuff after B completed, undoing
>>> B may already break stuff because changes were made after it completed,
>>> so the context in which it is undone has changed?
>>
>> Yep.
>>
>>
>>> You mention nested command stacks in papyrus. Maybe you can give us
>>> something clickable to see some code action? :)
>>
>> Sure thing:
>>
>> http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/gmfdiag/org.eclipse.papyrus.infra.gmfdiag.commands/src/org/eclipse/papyrus/commands/NestingNotifyingWorkspaceCommandStack.java
>>
>>
>> This addresses the problems you outlined by ensuring that nested
>> commands are executed but not presented in the undo history. Only the
>> top-level command is added to the history, and it captures the entirety
>> of the nested changes.
>>
>>
>>>
>>> Thanks,
>>> Felix
>>>
>>>
>>>
>>>> EMF Transactions don't share much of the semantics of transactions in
>>>> other systems such as databases, where one has the notion of transaction
>>>> isolation, durability, etc. It's a fairly light-weight editing layer on
>>>> top of the regular EMF editing domain, so I wouldn't expect many of the
>>>> technical problems of transaction nesting in other contexts to apply here.
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 2014-07-23 11:38:26 +0000, Erdal Karaca said:
>>>>
>>>>> Is the nested transactions support of the Transactions API expected to
>>>>> work "reliably" (for example, anything done in a recording command can
>>>>> be executed and undone, so I think it works "reliable").
>>>>>
>>>>> AFAIK, other frameowrks do not support nested transactions (for
>>>>> example, CDO or Hibernate). So, maybe that is something to acoid or
>>>>> would you say it is "mature" enough to use and/or is it a officially
>>>>> supported feature?
>>>>>
>>>>> Felix Dorner wrote on Tue, 22 July 2014 10:58
>>>>>> On 22/07/2014 10:23, Erdal Karaca wrote:
>>>>>>> Short question: Is it possible to determine if code is running inside a
>>>>>>> transaction, for example, within a RecordingCommand?
>>>>>>>
>>>>>>
>>>>>> You can use InternalTransactionalEditingDomain.getActiveTransaction()
>>>>>>
>>>>>>>
>>>>>>> Background: We have a "matured" thin API layer (facade) that provides
>>>>>>> access/modification to/of an ecore model (by hiding the internals of
>>>>>>> the
>>>>>>> transactions API). Sometimes, the facade is not sufficient to cover
>>>>>>> complex scenarios, so the logic has to be done within a recording
>>>>>>> command. Within the recording command, we would need to use the facade
>>>>>>> itself, but that is executing commands on the command stack which would
>>>>>>> lead to nested transactions.
>>>>>>
>>>>>> What's the problem with nested transactions?
>>>>>>
>>>>>> Felix
|
|
|
Goto Forum:
Current Time: Fri Apr 19 20:52:37 GMT 2024
Powered by FUDForum. Page generated in 0.03912 seconds |
] 
Search
Help
Register
Login
Home
