Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » TRANSACTION: using transactional editing domain from wizard
TRANSACTION: using transactional editing domain from wizard [message #417412] Sat, 08 March 2008 14:07 Go to next message
Larry is currently offline LarryFriend
Messages: 26
Registered: July 2009
Junior Member
My wizard action includes:
final TransactionEditingDomain domain = ...

try {

domain.runExclusive(new Runnable() {

public void run() {

Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(

new Runnable() {

public void run() {

//do stuff

}

}));}});

}catch (InterruptedException e) {

When I run it runExclusive notices that the wizard thread is the current
thread instead of the domain's thread and hangs starting a new txn. This
behavior seems to defeat the purpose of handing the stuff to the domain's
thread for execution.



As an aside, the help topic "sharing transactions with other threads",
refers incorrectly to Domain.syncExec() instead of
Domain.getDefault().syncExec().

Thanks!

Larry
Re: TRANSACTION: using transactional editing domain from wizard [message #417419 is a reply to message #417412] Mon, 10 March 2008 12:18 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Larry,

I should wait for Christian to answer but looking at the code, it seems
very wrong...

Larry Stevens wrote:
> My wizard action includes:
> final TransactionEditingDomain domain = ...
>
> try {
>
> domain.runExclusive(new Runnable() {
>
> public void run() {
>
> Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(
>
If the display thread is busy this will block and be delayed. If the
display thread itself is locked, this will deadlock. It seems
dangerous. The display knows nothing of transactions, so don't expect
the display's exec mechanisms to do anything smart with regard to
transactions...
> new Runnable() {
>
> public void run() {
>
> //do stuff
>
> }
>
> }));}});
>
> }catch (InterruptedException e) {
>
> When I run it runExclusive notices that the wizard thread is the current
> thread instead of the domain's thread and hangs starting a new txn.
I suspect this is because the transaction immediately tries to run
something on the display thread in a way that blocks the transaction
until it's done. What goal is this trying to accomplish?
> This
> behavior seems to defeat the purpose of handing the stuff to the domain's
> thread for execution.
>
Yes. But asking a transaction to do something that blocks until the GUI
thread does something seems self defeating.
>
>
> As an aside, the help topic "sharing transactions with other threads",
> refers incorrectly to Domain.syncExec() instead of
> Domain.getDefault().syncExec().
>
Maybe the transaction should be doing whatever non-GUI work it needs to
do and then hand off further processing to the GUI thread via an
asyncExec which then can acquire a lock of its own. Then again, maybe I
don't know what I'm talking about. Christian will correct me I'm sure.
> Thanks!
>
> Larry
>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: TRANSACTION: using transactional editing domain from wizard [message #417422 is a reply to message #417419] Mon, 10 March 2008 13:30 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Larry, Ed,

I can only add a bit of elaboration (in-line) on Ed's responses.

HTH,

Christian


Ed Merks wrote:

> Larry,
>
> I should wait for Christian to answer but looking at the code, it seems
> very wrong...
>
> Larry Stevens wrote:
>> My wizard action includes:
>> final TransactionEditingDomain domain = ...
>>
>> try {
>>
>> domain.runExclusive(new Runnable() {
>>
>> public void run() {
>>
>> Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(
>>
> If the display thread is busy this will block and be delayed. If the
> display thread itself is locked, this will deadlock. It seems
> dangerous. The display knows nothing of transactions, so don't expect
> the display's exec mechanisms to do anything smart with regard to
> transactions...

There wouldn't be much point in starting a transaction on a thread when all
that it intends to do is call Display.syncExec() to do a transaction on the
UI thread.

Try simply this:

Display.getDefault().syncExec(new Runnable() {
private boolean inTransaction;

public void run() {
if (inTransaction) {
// do stuff
} else {
try {
inTransaction = true;
domain.runExclusive(this);
} catch (...) {
...
} finally {
inTransaction = false;
}
}
});

Also, the wizard code is probably running on a ModalContext thread, and that
can be very tricky because the modal context has special knowledge of the
UI thread and actually takes over some of its responsibilities temporarily.
For example, it handles window-system events but ignores async runnables.


>> new Runnable() {
>>
>> public void run() {
>>
>> //do stuff
>>
>> }
>>
>> }));}});
>>
>> }catch (InterruptedException e) {
>>
>> When I run it runExclusive notices that the wizard thread is the current
>> thread instead of the domain's thread and hangs starting a new txn.
> I suspect this is because the transaction immediately tries to run
> something on the display thread in a way that blocks the transaction
> until it's done. What goal is this trying to accomplish?
>> This
>> behavior seems to defeat the purpose of handing the stuff to the domain's
>> thread for execution.
>>
> Yes. But asking a transaction to do something that blocks until the GUI
> thread does something seems self defeating.

Well, sometimes code that needs to synchronize with the UI is invoked in a
transactional context against its will, which is why the privileged
runnable mechanism is provided. However, it doesn't seem necessary in this
case, where the code that is synchronizing with the UI is also creating the
transaction.


>> As an aside, the help topic "sharing transactions with other threads",
>> refers incorrectly to Domain.syncExec() instead of
>> Domain.getDefault().syncExec().

I expect that the documentation refers to Display.syncExec() merely as a
qualified reference to the syncExec() API, not intending it as an example
of an actual invocation. Sometimes the default display is not the
appropriate choice, as in a multiple-display environment. Usually, it is
safest to get the display context from some appropriate widget, such as a
workbench-window shell.


> Maybe the transaction should be doing whatever non-GUI work it needs to
> do and then hand off further processing to the GUI thread via an
> asyncExec which then can acquire a lock of its own. Then again, maybe I
> don't know what I'm talking about. Christian will correct me I'm sure.

Well, sometimes synchronous communication between threads is simply
required. That's quite normal. OTOH, sometimes an asynchronous design can
be employed, instead.


>> Thanks!
>>
>> Larry
>>
>>
>>
Re: TRANSACTION: using transactional editing domain from wizard [message #417423 is a reply to message #417419] Mon, 10 March 2008 13:33 Go to previous messageGo to next message
Larry is currently offline LarryFriend
Messages: 26
Registered: July 2009
Junior Member
"What goal is this trying to accomplish?"

I'm trying to modify objects in the editing domain. The
TransactionChangeRecorder objects to the changes because they are being made
in the wizard's thread instead of the editing domain's thread. This code
(copying the doc) is attempting to hand the change actions to the other
thread.

And of course, I meant Display.getDefault().synchExec()
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fr38up$fmv$1@build.eclipse.org...
> Larry,
>
> I should wait for Christian to answer but looking at the code, it seems
> very wrong...
>
> Larry Stevens wrote:
>> My wizard action includes:
>> final TransactionEditingDomain domain = ...
>>
>> try {
>>
>> domain.runExclusive(new Runnable() {
>>
>> public void run() {
>>
>> Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(
>>
> If the display thread is busy this will block and be delayed. If the
> display thread itself is locked, this will deadlock. It seems dangerous.
> The display knows nothing of transactions, so don't expect the display's
> exec mechanisms to do anything smart with regard to transactions...
>> new Runnable() {
>>
>> public void run() {
>>
>> //do stuff
>>
>> }
>>
>> }));}});
>>
>> }catch (InterruptedException e) {
>>
>> When I run it runExclusive notices that the wizard thread is the current
>> thread instead of the domain's thread and hangs starting a new txn.
> I suspect this is because the transaction immediately tries to run
> something on the display thread in a way that blocks the transaction until
> it's done. What goal is this trying to accomplish?
>> This behavior seems to defeat the purpose of handing the stuff to the
>> domain's thread for execution.
>>
> Yes. But asking a transaction to do something that blocks until the GUI
> thread does something seems self defeating.
>>
>>
>> As an aside, the help topic "sharing transactions with other threads",
>> refers incorrectly to Domain.syncExec() instead of
>> Domain.getDefault().syncExec().
>>
> Maybe the transaction should be doing whatever non-GUI work it needs to do
> and then hand off further processing to the GUI thread via an asyncExec
> which then can acquire a lock of its own. Then again, maybe I don't know
> what I'm talking about. Christian will correct me I'm sure.
>> Thanks!
>>
>> Larry
>>
>>
>>
Re: TRANSACTION: using transactional editing domain from wizard [message #417424 is a reply to message #417423] Mon, 10 March 2008 13:37 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010504090301070507020104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Larry,

That much I understood, but you're immediately tossing control back to
the GUI thread. I don't understand that part. Likely you started on
the GUI thread in the first place. Hopefully Christian's information is
more clear than mine...


Larry Stevens wrote:
> "What goal is this trying to accomplish?"
>
> I'm trying to modify objects in the editing domain. The
> TransactionChangeRecorder objects to the changes because they are being made
> in the wizard's thread instead of the editing domain's thread. This code
> (copying the doc) is attempting to hand the change actions to the other
> thread.
>
> And of course, I meant Display.getDefault().synchExec()
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fr38up$fmv$1@build.eclipse.org...
>
>> Larry,
>>
>> I should wait for Christian to answer but looking at the code, it seems
>> very wrong...
>>
>> Larry Stevens wrote:
>>
>>> My wizard action includes:
>>> final TransactionEditingDomain domain = ...
>>>
>>> try {
>>>
>>> domain.runExclusive(new Runnable() {
>>>
>>> public void run() {
>>>
>>> Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(
>>>
>>>
>> If the display thread is busy this will block and be delayed. If the
>> display thread itself is locked, this will deadlock. It seems dangerous.
>> The display knows nothing of transactions, so don't expect the display's
>> exec mechanisms to do anything smart with regard to transactions...
>>
>>> new Runnable() {
>>>
>>> public void run() {
>>>
>>> //do stuff
>>>
>>> }
>>>
>>> }));}});
>>>
>>> }catch (InterruptedException e) {
>>>
>>> When I run it runExclusive notices that the wizard thread is the current
>>> thread instead of the domain's thread and hangs starting a new txn.
>>>
>> I suspect this is because the transaction immediately tries to run
>> something on the display thread in a way that blocks the transaction until
>> it's done. What goal is this trying to accomplish?
>>
>>> This behavior seems to defeat the purpose of handing the stuff to the
>>> domain's thread for execution.
>>>
>>>
>> Yes. But asking a transaction to do something that blocks until the GUI
>> thread does something seems self defeating.
>>
>>> As an aside, the help topic "sharing transactions with other threads",
>>> refers incorrectly to Domain.syncExec() instead of
>>> Domain.getDefault().syncExec().
>>>
>>>
>> Maybe the transaction should be doing whatever non-GUI work it needs to do
>> and then hand off further processing to the GUI thread via an asyncExec
>> which then can acquire a lock of its own. Then again, maybe I don't know
>> what I'm talking about. Christian will correct me I'm sure.
>>
>>> Thanks!
>>>
>>> Larry
>>>
>>>
>>>
>>>
>
>
>


--------------010504090301070507020104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Larry,<br>
<br>
That much I understood, but you're immediately tossing control back to
the GUI thread.&nbsp; I don't understand that part.&nbsp; Likely you started on
the GUI thread in the first place.&nbsp; Hopefully Christian's information
is more clear than mine...<br>
<br>
<br>
Larry Stevens wrote:
<blockquote cite="mid:fr3dc2$bj0$1@build.eclipse.org" type="cite">
<pre wrap="">"What goal is this trying to accomplish?"

I'm trying to modify objects in the editing domain. The
TransactionChangeRecorder objects to the changes because they are being made
in the wizard's thread instead of the editing domain's thread. This code
(copying the doc) is attempting to hand the change actions to the other
thread.

And of course, I meant Display.getDefault().synchExec()
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fr38up$fmv$1@build.eclipse.org">news:fr38up$fmv$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Larry,

I should wait for Christian to answer but looking at the code, it seems
very wrong...

Larry Stevens wrote:
</pre>
<blockquote type="cite">
<pre wrap="">My wizard action includes:
final TransactionEditingDomain domain = ...

try {

domain.runExclusive(new Runnable() {

public void run() {

Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(

</pre>
</blockquote>
<pre wrap="">If the display thread is busy this will block and be delayed. If the
display thread itself is locked, this will deadlock. It seems dangerous.
The display knows nothing of transactions, so don't expect the display's
exec mechanisms to do anything smart with regard to transactions...
</pre>
<blockquote type="cite">
<pre wrap=""> new Runnable() {

public void run() {

//do stuff

}

}));}});

}catch (InterruptedException e) {

When I run it runExclusive notices that the wizard thread is the current
thread instead of the domain's thread and hangs starting a new txn.
</pre>
</blockquote>
<pre wrap="">I suspect this is because the transaction immediately tries to run
something on the display thread in a way that blocks the transaction until
it's done. What goal is this trying to accomplish?
</pre>
<blockquote type="cite">
<pre wrap=""> This behavior seems to defeat the purpose of handing the stuff to the
domain's thread for execution.

</pre>
</blockquote>
<pre wrap="">Yes. But asking a transaction to do something that blocks until the GUI
thread does something seems self defeating.
</pre>
<blockquote type="cite">
<pre wrap="">
As an aside, the help topic "sharing transactions with other threads",
refers incorrectly to Domain.syncExec() instead of
Domain.getDefault().syncExec().

</pre>
</blockquote>
<pre wrap="">Maybe the transaction should be doing whatever non-GUI work it needs to do
and then hand off further processing to the GUI thread via an asyncExec
which then can acquire a lock of its own. Then again, maybe I don't know
what I'm talking about. Christian will correct me I'm sure.
</pre>
<blockquote type="cite">
<pre wrap="">Thanks!

Larry



</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
<br>
</body>
</html>

--------------010504090301070507020104--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: TRANSACTION: using transactional editing domain from wizard [message #417425 is a reply to message #417422] Mon, 10 March 2008 14:03 Go to previous messageGo to next message
Larry is currently offline LarryFriend
Messages: 26
Registered: July 2009
Junior Member
Thanks Christian

When I run with this variation,

Display.getDefault().syncExec(new Runnable() {
private boolean inTransaction;

public void run() {
if (inTransaction) {
// do stuff
} else {
try {
inTransaction = true;
domain.runExclusive(this);
} catch (...) {
...
} finally {
inTransaction = false;
}
}
}});

TransactionChangeRecorder.assertWrite() stilll objects that the domain
thread doesn't match the current thread.

Larry
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fr3d59$998$1@build.eclipse.org...
> Hi, Larry, Ed,
>
> I can only add a bit of elaboration (in-line) on Ed's responses.
>
> HTH,
>
> Christian
>
>
> Ed Merks wrote:
>
>> Larry,
>>
>> I should wait for Christian to answer but looking at the code, it seems
>> very wrong...
>>
>> Larry Stevens wrote:
>>> My wizard action includes:
>>> final TransactionEditingDomain domain = ...
>>>
>>> try {
>>>
>>> domain.runExclusive(new Runnable() {
>>>
>>> public void run() {
>>>
>>> Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(
>>>
>> If the display thread is busy this will block and be delayed. If the
>> display thread itself is locked, this will deadlock. It seems
>> dangerous. The display knows nothing of transactions, so don't expect
>> the display's exec mechanisms to do anything smart with regard to
>> transactions...
>
> There wouldn't be much point in starting a transaction on a thread when
> all
> that it intends to do is call Display.syncExec() to do a transaction on
> the
> UI thread.
>
> Try simply this:
>
> Display.getDefault().syncExec(new Runnable() {
> private boolean inTransaction;
>
> public void run() {
> if (inTransaction) {
> // do stuff
> } else {
> try {
> inTransaction = true;
> domain.runExclusive(this);
> } catch (...) {
> ...
> } finally {
> inTransaction = false;
> }
> }
> });
>
> Also, the wizard code is probably running on a ModalContext thread, and
> that
> can be very tricky because the modal context has special knowledge of the
> UI thread and actually takes over some of its responsibilities
> temporarily.
> For example, it handles window-system events but ignores async runnables.
>
>
>>> new Runnable() {
>>>
>>> public void run() {
>>>
>>> //do stuff
>>>
>>> }
>>>
>>> }));}});
>>>
>>> }catch (InterruptedException e) {
>>>
>>> When I run it runExclusive notices that the wizard thread is the current
>>> thread instead of the domain's thread and hangs starting a new txn.
>> I suspect this is because the transaction immediately tries to run
>> something on the display thread in a way that blocks the transaction
>> until it's done. What goal is this trying to accomplish?
>>> This
>>> behavior seems to defeat the purpose of handing the stuff to the
>>> domain's
>>> thread for execution.
>>>
>> Yes. But asking a transaction to do something that blocks until the GUI
>> thread does something seems self defeating.
>
> Well, sometimes code that needs to synchronize with the UI is invoked in a
> transactional context against its will, which is why the privileged
> runnable mechanism is provided. However, it doesn't seem necessary in
> this
> case, where the code that is synchronizing with the UI is also creating
> the
> transaction.
>
>
>>> As an aside, the help topic "sharing transactions with other threads",
>>> refers incorrectly to Domain.syncExec() instead of
>>> Domain.getDefault().syncExec().
>
> I expect that the documentation refers to Display.syncExec() merely as a
> qualified reference to the syncExec() API, not intending it as an example
> of an actual invocation. Sometimes the default display is not the
> appropriate choice, as in a multiple-display environment. Usually, it is
> safest to get the display context from some appropriate widget, such as a
> workbench-window shell.
>
>
>> Maybe the transaction should be doing whatever non-GUI work it needs to
>> do and then hand off further processing to the GUI thread via an
>> asyncExec which then can acquire a lock of its own. Then again, maybe I
>> don't know what I'm talking about. Christian will correct me I'm sure.
>
> Well, sometimes synchronous communication between threads is simply
> required. That's quite normal. OTOH, sometimes an asynchronous design
> can
> be employed, instead.
>
>
>>> Thanks!
>>>
>>> Larry
>>>
>>>
>>>
>
Re: TRANSACTION: using transactional editing domain from wizard [message #417426 is a reply to message #417425] Mon, 10 March 2008 14:38 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060802030401040101000202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Larry,

The Javadoc is pretty clear that runExclusive is for doing a read-only thing

* Runs an operation that requires exclusive access to my resource set,
* for reading. The specified runnable is executed in a read-only
* transaction

If you're trying to make changes to the model, you'd need to do that as
a command so that the result is undoable...


Larry Stevens wrote:
> Thanks Christian
>
> When I run with this variation,
>
> Display.getDefault().syncExec(new Runnable() {
> private boolean inTransaction;
>
> public void run() {
> if (inTransaction) {
> // do stuff
> } else {
> try {
> inTransaction = true;
> domain.runExclusive(this);
> } catch (...) {
> ...
> } finally {
> inTransaction = false;
> }
> }
> }});
>
> TransactionChangeRecorder.assertWrite() stilll objects that the domain
> thread doesn't match the current thread.
>
> Larry
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fr3d59$998$1@build.eclipse.org...
>
>> Hi, Larry, Ed,
>>
>> I can only add a bit of elaboration (in-line) on Ed's responses.
>>
>> HTH,
>>
>> Christian
>>
>>
>> Ed Merks wrote:
>>
>>
>>> Larry,
>>>
>>> I should wait for Christian to answer but looking at the code, it seems
>>> very wrong...
>>>
>>> Larry Stevens wrote:
>>>
>>>> My wizard action includes:
>>>> final TransactionEditingDomain domain = ...
>>>>
>>>> try {
>>>>
>>>> domain.runExclusive(new Runnable() {
>>>>
>>>> public void run() {
>>>>
>>>> Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(
>>>>
>>>>
>>> If the display thread is busy this will block and be delayed. If the
>>> display thread itself is locked, this will deadlock. It seems
>>> dangerous. The display knows nothing of transactions, so don't expect
>>> the display's exec mechanisms to do anything smart with regard to
>>> transactions...
>>>
>> There wouldn't be much point in starting a transaction on a thread when
>> all
>> that it intends to do is call Display.syncExec() to do a transaction on
>> the
>> UI thread.
>>
>> Try simply this:
>>
>> Display.getDefault().syncExec(new Runnable() {
>> private boolean inTransaction;
>>
>> public void run() {
>> if (inTransaction) {
>> // do stuff
>> } else {
>> try {
>> inTransaction = true;
>> domain.runExclusive(this);
>> } catch (...) {
>> ...
>> } finally {
>> inTransaction = false;
>> }
>> }
>> });
>>
>> Also, the wizard code is probably running on a ModalContext thread, and
>> that
>> can be very tricky because the modal context has special knowledge of the
>> UI thread and actually takes over some of its responsibilities
>> temporarily.
>> For example, it handles window-system events but ignores async runnables.
>>
>>
>>
>>>> new Runnable() {
>>>>
>>>> public void run() {
>>>>
>>>> //do stuff
>>>>
>>>> }
>>>>
>>>> }));}});
>>>>
>>>> }catch (InterruptedException e) {
>>>>
>>>> When I run it runExclusive notices that the wizard thread is the current
>>>> thread instead of the domain's thread and hangs starting a new txn.
>>>>
>>> I suspect this is because the transaction immediately tries to run
>>> something on the display thread in a way that blocks the transaction
>>> until it's done. What goal is this trying to accomplish?
>>>
>>>> This
>>>> behavior seems to defeat the purpose of handing the stuff to the
>>>> domain's
>>>> thread for execution.
>>>>
>>>>
>>> Yes. But asking a transaction to do something that blocks until the GUI
>>> thread does something seems self defeating.
>>>
>> Well, sometimes code that needs to synchronize with the UI is invoked in a
>> transactional context against its will, which is why the privileged
>> runnable mechanism is provided. However, it doesn't seem necessary in
>> this
>> case, where the code that is synchronizing with the UI is also creating
>> the
>> transaction.
>>
>>
>>
>>>> As an aside, the help topic "sharing transactions with other threads",
>>>> refers incorrectly to Domain.syncExec() instead of
>>>> Domain.getDefault().syncExec().
>>>>
>> I expect that the documentation refers to Display.syncExec() merely as a
>> qualified reference to the syncExec() API, not intending it as an example
>> of an actual invocation. Sometimes the default display is not the
>> appropriate choice, as in a multiple-display environment. Usually, it is
>> safest to get the display context from some appropriate widget, such as a
>> workbench-window shell.
>>
>>
>>
>>> Maybe the transaction should be doing whatever non-GUI work it needs to
>>> do and then hand off further processing to the GUI thread via an
>>> asyncExec which then can acquire a lock of its own. Then again, maybe I
>>> don't know what I'm talking about. Christian will correct me I'm sure.
>>>
>> Well, sometimes synchronous communication between threads is simply
>> required. That's quite normal. OTOH, sometimes an asynchronous design
>> can
>> be employed, instead.
>>
>>
>>
>>>> Thanks!
>>>>
>>>> Larry
>>>>
>>>>
>>>>
>>>>
>
>
>


--------------060802030401040101000202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Larry,<br>
<br>
The Javadoc is pretty clear that runExclusive is for doing a read-only
thing<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; * Runs an operation that requires exclusive access to my resource
set,<br>
&nbsp;&nbsp;&nbsp; &nbsp;* for reading.&nbsp; The specified runnable is executed in a read-only<br>
&nbsp;&nbsp;&nbsp; &nbsp;* transaction<br>
<br>
If you're trying to make changes to the model, you'd need to do that as
a command so that the result is undoable...<br>
<br>
<br>
Larry Stevens wrote:
<blockquote cite="mid:fr3f48$s8c$1@build.eclipse.org" type="cite">
<pre wrap="">Thanks Christian

When I run with this variation,

Display.getDefault().syncExec(new Runnable() {
private boolean inTransaction;

public void run() {
if (inTransaction) {
// do stuff
} else {
try {
inTransaction = true;
domain.runExclusive(this);
} catch (...) {
...
} finally {
inTransaction = false;
}
}
}});

TransactionChangeRecorder.assertWrite() stilll objects that the domain
thread doesn't match the current thread.

Larry
"Christian W. Damus" <a class="moz-txt-link-rfc2396E" href="mailto:cdamus@ca.ibm.com">&lt;cdamus@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fr3d59$998$1@build.eclipse.org">news:fr3d59$998$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi, Larry, Ed,

I can only add a bit of elaboration (in-line) on Ed's responses.

HTH,

Christian


Ed Merks wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Larry,

I should wait for Christian to answer but looking at the code, it seems
very wrong...

Larry Stevens wrote:
</pre>
<blockquote type="cite">
<pre wrap="">My wizard action includes:
final TransactionEditingDomain domain = ...

try {

domain.runExclusive(new Runnable() {

public void run() {

Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(

</pre>
</blockquote>
<pre wrap="">If the display thread is busy this will block and be delayed. If the
display thread itself is locked, this will deadlock. It seems
dangerous. The display knows nothing of transactions, so don't expect
the display's exec mechanisms to do anything smart with regard to
transactions...
</pre>
</blockquote>
<pre wrap="">There wouldn't be much point in starting a transaction on a thread when
all
that it intends to do is call Display.syncExec() to do a transaction on
the
UI thread.

Try simply this:

Display.getDefault().syncExec(new Runnable() {
private boolean inTransaction;

public void run() {
if (inTransaction) {
// do stuff
} else {
try {
inTransaction = true;
domain.runExclusive(this);
} catch (...) {
...
} finally {
inTransaction = false;
}
}
});

Also, the wizard code is probably running on a ModalContext thread, and
that
can be very tricky because the modal context has special knowledge of the
UI thread and actually takes over some of its responsibilities
temporarily.
For example, it handles window-system events but ignores async runnables.


</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> new Runnable() {

public void run() {

//do stuff

}

}));}});

}catch (InterruptedException e) {

When I run it runExclusive notices that the wizard thread is the current
thread instead of the domain's thread and hangs starting a new txn.
</pre>
</blockquote>
<pre wrap="">I suspect this is because the transaction immediately tries to run
something on the display thread in a way that blocks the transaction
until it's done. What goal is this trying to accomplish?
</pre>
<blockquote type="cite">
<pre wrap=""> This
behavior seems to defeat the purpose of handing the stuff to the
domain's
thread for execution.

</pre>
</blockquote>
<pre wrap="">Yes. But asking a transaction to do something that blocks until the GUI
thread does something seems self defeating.
</pre>
</blockquote>
<pre wrap="">Well, sometimes code that needs to synchronize with the UI is invoked in a
transactional context against its will, which is why the privileged
runnable mechanism is provided. However, it doesn't seem necessary in
this
case, where the code that is synchronizing with the UI is also creating
the
transaction.


</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">As an aside, the help topic "sharing transactions with other threads",
refers incorrectly to Domain.syncExec() instead of
Domain.getDefault().syncExec().
</pre>
</blockquote>
</blockquote>
<pre wrap="">I expect that the documentation refers to Display.syncExec() merely as a
qualified reference to the syncExec() API, not intending it as an example
of an actual invocation. Sometimes the default display is not the
appropriate choice, as in a multiple-display environment. Usually, it is
safest to get the display context from some appropriate widget, such as a
workbench-window shell.


</pre>
<blockquote type="cite">
<pre wrap="">Maybe the transaction should be doing whatever non-GUI work it needs to
do and then hand off further processing to the GUI thread via an
asyncExec which then can acquire a lock of its own. Then again, maybe I
don't know what I'm talking about. Christian will correct me I'm sure.
</pre>
</blockquote>
<pre wrap="">Well, sometimes synchronous communication between threads is simply
required. That's quite normal. OTOH, sometimes an asynchronous design
can
be employed, instead.


</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Thanks!

Larry



</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
<br>
</body>
</html>

--------------060802030401040101000202--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: TRANSACTION: using transactional editing domain from wizard [message #417429 is a reply to message #417425] Mon, 10 March 2008 15:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Larry,

Sorry, I seem to have failed to notice that you are attempting to modify the
contents of your resource set. Not a good start to my week :-(

the runExclusive() API gives the current thread only read-only access to the
resource set. In order to modify, you need read/write access, which is
provided by execution of a command.

Try this:

Display.getDefault().syncExec(new Runnable() {
public void run() {
try {
domain.getCommandStack().execute(
new RecordingCommand(domain, "some label") {
... doExecute(...) { /* do stuff */ }
});
} catch (...) {
...
}
}});

HTH,

Christian


Larry Stevens wrote:

> Thanks Christian
>
> When I run with this variation,
>
> Display.getDefault().syncExec(new Runnable() {
> private boolean inTransaction;
>
> public void run() {
> if (inTransaction) {
> // do stuff
> } else {
> try {
> inTransaction = true;
> domain.runExclusive(this);
> } catch (...) {
> ...
> } finally {
> inTransaction = false;
> }
> }
> }});
>
> TransactionChangeRecorder.assertWrite() stilll objects that the domain
> thread doesn't match the current thread.
>
> Larry
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fr3d59$998$1@build.eclipse.org...
>> Hi, Larry, Ed,
>>
>> I can only add a bit of elaboration (in-line) on Ed's responses.
>>
>> HTH,
>>
>> Christian
>>
>>
>> Ed Merks wrote:
>>
>>> Larry,
>>>
>>> I should wait for Christian to answer but looking at the code, it seems
>>> very wrong...
>>>
>>> Larry Stevens wrote:
>>>> My wizard action includes:
>>>> final TransactionEditingDomain domain = ...
>>>>
>>>> try {
>>>>
>>>> domain.runExclusive(new Runnable() {
>>>>
>>>> public void run() {
>>>>
>>>> Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(
>>>>
>>> If the display thread is busy this will block and be delayed. If the
>>> display thread itself is locked, this will deadlock. It seems
>>> dangerous. The display knows nothing of transactions, so don't expect
>>> the display's exec mechanisms to do anything smart with regard to
>>> transactions...
>>
>> There wouldn't be much point in starting a transaction on a thread when
>> all
>> that it intends to do is call Display.syncExec() to do a transaction on
>> the
>> UI thread.
>>
>> Try simply this:
>>
>> Display.getDefault().syncExec(new Runnable() {
>> private boolean inTransaction;
>>
>> public void run() {
>> if (inTransaction) {
>> // do stuff
>> } else {
>> try {
>> inTransaction = true;
>> domain.runExclusive(this);
>> } catch (...) {
>> ...
>> } finally {
>> inTransaction = false;
>> }
>> }
>> });
>>
>> Also, the wizard code is probably running on a ModalContext thread, and
>> that
>> can be very tricky because the modal context has special knowledge of the
>> UI thread and actually takes over some of its responsibilities
>> temporarily.
>> For example, it handles window-system events but ignores async runnables.
>>
>>
>>>> new Runnable() {
>>>>
>>>> public void run() {
>>>>
>>>> //do stuff
>>>>
>>>> }
>>>>
>>>> }));}});
>>>>
>>>> }catch (InterruptedException e) {
>>>>
>>>> When I run it runExclusive notices that the wizard thread is the
>>>> current thread instead of the domain's thread and hangs starting a new
>>>> txn.
>>> I suspect this is because the transaction immediately tries to run
>>> something on the display thread in a way that blocks the transaction
>>> until it's done. What goal is this trying to accomplish?
>>>> This
>>>> behavior seems to defeat the purpose of handing the stuff to the
>>>> domain's
>>>> thread for execution.
>>>>
>>> Yes. But asking a transaction to do something that blocks until the GUI
>>> thread does something seems self defeating.
>>
>> Well, sometimes code that needs to synchronize with the UI is invoked in
>> a transactional context against its will, which is why the privileged
>> runnable mechanism is provided. However, it doesn't seem necessary in
>> this
>> case, where the code that is synchronizing with the UI is also creating
>> the
>> transaction.
>>
>>
>>>> As an aside, the help topic "sharing transactions with other threads",
>>>> refers incorrectly to Domain.syncExec() instead of
>>>> Domain.getDefault().syncExec().
>>
>> I expect that the documentation refers to Display.syncExec() merely as a
>> qualified reference to the syncExec() API, not intending it as an example
>> of an actual invocation. Sometimes the default display is not the
>> appropriate choice, as in a multiple-display environment. Usually, it is
>> safest to get the display context from some appropriate widget, such as a
>> workbench-window shell.
>>
>>
>>> Maybe the transaction should be doing whatever non-GUI work it needs to
>>> do and then hand off further processing to the GUI thread via an
>>> asyncExec which then can acquire a lock of its own. Then again, maybe I
>>> don't know what I'm talking about. Christian will correct me I'm sure.
>>
>> Well, sometimes synchronous communication between threads is simply
>> required. That's quite normal. OTOH, sometimes an asynchronous design
>> can
>> be employed, instead.
>>
>>
>>>> Thanks!
>>>>
>>>> Larry
>>>>
>>>>
>>>>
>>
Re: TRANSACTION: using transactional editing domain from wizard [message #417438 is a reply to message #417429] Mon, 10 March 2008 18:45 Go to previous message
Larry is currently offline LarryFriend
Messages: 26
Registered: July 2009
Junior Member
That was it...Thanks!
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fr3lel$gka$1@build.eclipse.org...
> Hi, Larry,
>
> Sorry, I seem to have failed to notice that you are attempting to modify
> the
> contents of your resource set. Not a good start to my week :-(
>
> the runExclusive() API gives the current thread only read-only access to
> the
> resource set. In order to modify, you need read/write access, which is
> provided by execution of a command.
>
> Try this:
>
> Display.getDefault().syncExec(new Runnable() {
> public void run() {
> try {
> domain.getCommandStack().execute(
> new RecordingCommand(domain, "some label") {
> ... doExecute(...) { /* do stuff */ }
> });
> } catch (...) {
> ...
> }
> }});
>
> HTH,
>
> Christian
>
>
> Larry Stevens wrote:
>
>> Thanks Christian
>>
>> When I run with this variation,
>>
>> Display.getDefault().syncExec(new Runnable() {
>> private boolean inTransaction;
>>
>> public void run() {
>> if (inTransaction) {
>> // do stuff
>> } else {
>> try {
>> inTransaction = true;
>> domain.runExclusive(this);
>> } catch (...) {
>> ...
>> } finally {
>> inTransaction = false;
>> }
>> }
>> }});
>>
>> TransactionChangeRecorder.assertWrite() stilll objects that the domain
>> thread doesn't match the current thread.
>>
>> Larry
>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>> news:fr3d59$998$1@build.eclipse.org...
>>> Hi, Larry, Ed,
>>>
>>> I can only add a bit of elaboration (in-line) on Ed's responses.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>> Larry,
>>>>
>>>> I should wait for Christian to answer but looking at the code, it seems
>>>> very wrong...
>>>>
>>>> Larry Stevens wrote:
>>>>> My wizard action includes:
>>>>> final TransactionEditingDomain domain = ...
>>>>>
>>>>> try {
>>>>>
>>>>> domain.runExclusive(new Runnable() {
>>>>>
>>>>> public void run() {
>>>>>
>>>>> Display.getDefault().syncExec(domain.createPrivilegedRunnabl e(
>>>>>
>>>> If the display thread is busy this will block and be delayed. If the
>>>> display thread itself is locked, this will deadlock. It seems
>>>> dangerous. The display knows nothing of transactions, so don't expect
>>>> the display's exec mechanisms to do anything smart with regard to
>>>> transactions...
>>>
>>> There wouldn't be much point in starting a transaction on a thread when
>>> all
>>> that it intends to do is call Display.syncExec() to do a transaction on
>>> the
>>> UI thread.
>>>
>>> Try simply this:
>>>
>>> Display.getDefault().syncExec(new Runnable() {
>>> private boolean inTransaction;
>>>
>>> public void run() {
>>> if (inTransaction) {
>>> // do stuff
>>> } else {
>>> try {
>>> inTransaction = true;
>>> domain.runExclusive(this);
>>> } catch (...) {
>>> ...
>>> } finally {
>>> inTransaction = false;
>>> }
>>> }
>>> });
>>>
>>> Also, the wizard code is probably running on a ModalContext thread, and
>>> that
>>> can be very tricky because the modal context has special knowledge of
>>> the
>>> UI thread and actually takes over some of its responsibilities
>>> temporarily.
>>> For example, it handles window-system events but ignores async
>>> runnables.
>>>
>>>
>>>>> new Runnable() {
>>>>>
>>>>> public void run() {
>>>>>
>>>>> //do stuff
>>>>>
>>>>> }
>>>>>
>>>>> }));}});
>>>>>
>>>>> }catch (InterruptedException e) {
>>>>>
>>>>> When I run it runExclusive notices that the wizard thread is the
>>>>> current thread instead of the domain's thread and hangs starting a new
>>>>> txn.
>>>> I suspect this is because the transaction immediately tries to run
>>>> something on the display thread in a way that blocks the transaction
>>>> until it's done. What goal is this trying to accomplish?
>>>>> This
>>>>> behavior seems to defeat the purpose of handing the stuff to the
>>>>> domain's
>>>>> thread for execution.
>>>>>
>>>> Yes. But asking a transaction to do something that blocks until the
>>>> GUI
>>>> thread does something seems self defeating.
>>>
>>> Well, sometimes code that needs to synchronize with the UI is invoked in
>>> a transactional context against its will, which is why the privileged
>>> runnable mechanism is provided. However, it doesn't seem necessary in
>>> this
>>> case, where the code that is synchronizing with the UI is also creating
>>> the
>>> transaction.
>>>
>>>
>>>>> As an aside, the help topic "sharing transactions with other threads",
>>>>> refers incorrectly to Domain.syncExec() instead of
>>>>> Domain.getDefault().syncExec().
>>>
>>> I expect that the documentation refers to Display.syncExec() merely as a
>>> qualified reference to the syncExec() API, not intending it as an
>>> example
>>> of an actual invocation. Sometimes the default display is not the
>>> appropriate choice, as in a multiple-display environment. Usually, it
>>> is
>>> safest to get the display context from some appropriate widget, such as
>>> a
>>> workbench-window shell.
>>>
>>>
>>>> Maybe the transaction should be doing whatever non-GUI work it needs to
>>>> do and then hand off further processing to the GUI thread via an
>>>> asyncExec which then can acquire a lock of its own. Then again, maybe I
>>>> don't know what I'm talking about. Christian will correct me I'm sure.
>>>
>>> Well, sometimes synchronous communication between threads is simply
>>> required. That's quite normal. OTOH, sometimes an asynchronous design
>>> can
>>> be employed, instead.
>>>
>>>
>>>>> Thanks!
>>>>>
>>>>> Larry
>>>>>
>>>>>
>>>>>
>>>
>
Previous Topic:One ecore:EPackage per .ecore file ?
Next Topic:Load with customized XML format
Goto Forum:
  


Current Time: Thu Mar 28 12:19:30 GMT 2024

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

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

Back to the top