Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [transaction] multi-threaded access to emf presentation model
[transaction] multi-threaded access to emf presentation model [message #431930] Thu, 30 July 2009 02:39 Go to next message
Will Horn is currently offline Will HornFriend
Messages: 265
Registered: July 2009
Senior Member
In my application, I am using EMF as UI/presentation model for a rich client
to a backend server. A simplified way to think about it is a tree view of
tasks that reflect work the server is doing. I can see the tasks,
start/stop them, and deploy new tasks to the server using a wizard.

Since the communication with the server could be slow, it needs to run in a
separate thread. So I need to be able to safely publish an EObject created
on the UI thread to a background thread (e.g. for deployment), and safely
update the UI model from a background thread (e.g. to reflect incoming
updates).

I think I can achieve this by carefully confining all reads and writes to
the model to the UI thread. In the deployment case, I'd have to copy the
EObject's fields into final/volatile variables for the background thread to
use. From the other direction, I would use a form of Display.asyncExec to
write to the model on the UI thread. I've also considered modifying the JET
templates to make fields volatile (Java volatile, not EMF volatile). This
doesn't work for collections, but it would simplify read-only access of
simple fields.

My question is: "Could EMF Transaction help me here?" It seems to be the
standard answer for multi-threaded use cases, but I am not sure exactly how
it addresses mine. My limited understanding of EMF Transaction (from the
javadocs) is that it would enforce all model reads and writes to be done in
a transaction and it uses a lock to ensure proper visibility across threads.
Is this a better approach? My EObjects are really a sort of glorified
JavaBeans that exist only in memory. I don't currently have a ResourceSet
or an EditingDomain, and neither are necessary on the UI side.

Thanks for any advice, or pointers to further documentation.
-Will
Re: [transaction] multi-threaded access to emf presentation model [message #431934 is a reply to message #431930] Thu, 30 July 2009 05:49 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Will,

I think the CDO Model Repository could help you with the mentioned
issues, and probably more. Not only CDO supports transactionality on
object level (EMF Transaction supports it on ResourceSet level and in
addition requires you to use commands to modify the model, IIRC). CDO
also shares model data among multiple transactions/views so that it's
rather cheap to create multiple transactions on the same session and
dedicate different threads to them. A proven pattern is to use a global
read-only view for all the UI lists and viewers and fork a transaction
in a background job for each modification action. Please let me know if
you would like more infos/pointers...

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Will Horn schrieb:
> In my application, I am using EMF as UI/presentation model for a rich
> client to a backend server. A simplified way to think about it is a
> tree view of tasks that reflect work the server is doing. I can see
> the tasks, start/stop them, and deploy new tasks to the server using a
> wizard.
>
> Since the communication with the server could be slow, it needs to run
> in a separate thread. So I need to be able to safely publish an
> EObject created on the UI thread to a background thread (e.g. for
> deployment), and safely update the UI model from a background thread
> (e.g. to reflect incoming updates).
>
> I think I can achieve this by carefully confining all reads and writes
> to the model to the UI thread. In the deployment case, I'd have to
> copy the EObject's fields into final/volatile variables for the
> background thread to use. From the other direction, I would use a
> form of Display.asyncExec to write to the model on the UI thread.
> I've also considered modifying the JET templates to make fields
> volatile (Java volatile, not EMF volatile). This doesn't work for
> collections, but it would simplify read-only access of simple fields.
>
> My question is: "Could EMF Transaction help me here?" It seems to be
> the standard answer for multi-threaded use cases, but I am not sure
> exactly how it addresses mine. My limited understanding of EMF
> Transaction (from the javadocs) is that it would enforce all model
> reads and writes to be done in a transaction and it uses a lock to
> ensure proper visibility across threads. Is this a better approach?
> My EObjects are really a sort of glorified JavaBeans that exist only
> in memory. I don't currently have a ResourceSet or an EditingDomain,
> and neither are necessary on the UI side.
>
> Thanks for any advice, or pointers to further documentation.
> -Will
>
>


Re: [transaction] multi-threaded access to emf presentation model [message #431955 is a reply to message #431930] Thu, 30 July 2009 14:27 Go to previous messageGo to next message
Boris Gruschko is currently offline Boris GruschkoFriend
Messages: 14
Registered: July 2009
Junior Member
Hi Will,

Transaction would help you, if (as you mentioned) you had a resource set and
a TransactionalEditingDomain. Furthermore, the changes of the model would
have to be wrapped in commands.

The Lock of Transaction provides for safe publishing and UI thread
decontention.

Please let me know if you need any help and cheers,
Boris

"Will Horn" <will.horn@gmail.com> wrote in message
news:h4r14d$d8u$1@build.eclipse.org...
> In my application, I am using EMF as UI/presentation model for a rich
> client to a backend server. A simplified way to think about it is a tree
> view of tasks that reflect work the server is doing. I can see the tasks,
> start/stop them, and deploy new tasks to the server using a wizard.
>
> Since the communication with the server could be slow, it needs to run in
> a separate thread. So I need to be able to safely publish an EObject
> created on the UI thread to a background thread (e.g. for deployment), and
> safely update the UI model from a background thread (e.g. to reflect
> incoming updates).
>
> I think I can achieve this by carefully confining all reads and writes to
> the model to the UI thread. In the deployment case, I'd have to copy the
> EObject's fields into final/volatile variables for the background thread
> to use. From the other direction, I would use a form of Display.asyncExec
> to write to the model on the UI thread. I've also considered modifying
> the JET templates to make fields volatile (Java volatile, not EMF
> volatile). This doesn't work for collections, but it would simplify
> read-only access of simple fields.
>
> My question is: "Could EMF Transaction help me here?" It seems to be the
> standard answer for multi-threaded use cases, but I am not sure exactly
> how it addresses mine. My limited understanding of EMF Transaction (from
> the javadocs) is that it would enforce all model reads and writes to be
> done in a transaction and it uses a lock to ensure proper visibility
> across threads. Is this a better approach? My EObjects are really a sort
> of glorified JavaBeans that exist only in memory. I don't currently have
> a ResourceSet or an EditingDomain, and neither are necessary on the UI
> side.
>
> Thanks for any advice, or pointers to further documentation.
> -Will
>
>
Re: [transaction] multi-threaded access to emf presentation model [message #434171 is a reply to message #431934] Thu, 30 July 2009 19:21 Go to previous messageGo to next message
Will Horn is currently offline Will HornFriend
Messages: 265
Registered: July 2009
Senior Member
Hi Eike,

Thanks for the response. Does CDO allow for a client side model repository
(maybe an in-memory one)? I noticed this wiki page which is empty
http://wiki.eclipse.org/Writing_Standalone_CDO_Applications :o)

I actually have watched your recent webinar with Ed Merks. My impression
was that CDO was intended for keeping multiple clients synchronized on a
shared EMF model. In my case the true model is on the server side and is
not EMF. My EObjects are local to a single client.

-Will


"Eike Stepper" <stepper@esc-net.de> wrote in message
news:h4rca9$o2b$2@build.eclipse.org...
> Will,
>
> I think the CDO Model Repository could help you with the mentioned
> issues, and probably more. Not only CDO supports transactionality on
> object level (EMF Transaction supports it on ResourceSet level and in
> addition requires you to use commands to modify the model, IIRC). CDO
> also shares model data among multiple transactions/views so that it's
> rather cheap to create multiple transactions on the same session and
> dedicate different threads to them. A proven pattern is to use a global
> read-only view for all the UI lists and viewers and fork a transaction
> in a background job for each modification action. Please let me know if
> you would like more infos/pointers...
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Will Horn schrieb:
>> In my application, I am using EMF as UI/presentation model for a rich
>> client to a backend server. A simplified way to think about it is a
>> tree view of tasks that reflect work the server is doing. I can see
>> the tasks, start/stop them, and deploy new tasks to the server using a
>> wizard.
>>
>> Since the communication with the server could be slow, it needs to run
>> in a separate thread. So I need to be able to safely publish an
>> EObject created on the UI thread to a background thread (e.g. for
>> deployment), and safely update the UI model from a background thread
>> (e.g. to reflect incoming updates).
>>
>> I think I can achieve this by carefully confining all reads and writes
>> to the model to the UI thread. In the deployment case, I'd have to
>> copy the EObject's fields into final/volatile variables for the
>> background thread to use. From the other direction, I would use a
>> form of Display.asyncExec to write to the model on the UI thread.
>> I've also considered modifying the JET templates to make fields
>> volatile (Java volatile, not EMF volatile). This doesn't work for
>> collections, but it would simplify read-only access of simple fields.
>>
>> My question is: "Could EMF Transaction help me here?" It seems to be
>> the standard answer for multi-threaded use cases, but I am not sure
>> exactly how it addresses mine. My limited understanding of EMF
>> Transaction (from the javadocs) is that it would enforce all model
>> reads and writes to be done in a transaction and it uses a lock to
>> ensure proper visibility across threads. Is this a better approach?
>> My EObjects are really a sort of glorified JavaBeans that exist only
>> in memory. I don't currently have a ResourceSet or an EditingDomain,
>> and neither are necessary on the UI side.
>>
>> Thanks for any advice, or pointers to further documentation.
>> -Will
>>
>>
Re: [transaction] multi-threaded access to emf presentation model [message #439625 is a reply to message #434171] Fri, 31 July 2009 06:23 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070004010809090008050906
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Will,

Comments below...


Will Horn schrieb:
> Hi Eike,
>
> Thanks for the response. Does CDO allow for a client side model
> repository (maybe an in-memory one)?
Sure, you can embed the repository into your application or use local
TCP. Apart from that you can choose a backend store type, including
MEMStore.

> I noticed this wiki page which is empty
> http://wiki.eclipse.org/Writing_Standalone_CDO_Applications :o)
Thx for the hint. I removed that link and info can be found in
http://wiki.eclipse.org/User_Contributed_CDO_Documentation

>
> I actually have watched your recent webinar with Ed Merks. My
> impression was that CDO was intended for keeping multiple clients
> synchronized on a shared EMF model.
Well, that's one of several intentions ;-)
A CDOSession can switch off this behaviour:

| session.options().setPassiveUpdateEnabled(*false*);|


> In my case the true model is on the server side and is not EMF.
Not EMF?? :P

> My EObjects are local to a single client.
Soon we'll release our new EmbeddedSessionProtocol which makes usage of
local repositories even faster and less memory hungry. In the meantime
you could play with the JVMConnector for the Net4j session type.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> -Will
>
>
> "Eike Stepper" <stepper@esc-net.de> wrote in message
> news:h4rca9$o2b$2@build.eclipse.org...
>> Will,
>>
>> I think the CDO Model Repository could help you with the mentioned
>> issues, and probably more. Not only CDO supports transactionality on
>> object level (EMF Transaction supports it on ResourceSet level and in
>> addition requires you to use commands to modify the model, IIRC). CDO
>> also shares model data among multiple transactions/views so that it's
>> rather cheap to create multiple transactions on the same session and
>> dedicate different threads to them. A proven pattern is to use a global
>> read-only view for all the UI lists and viewers and fork a transaction
>> in a background job for each modification action. Please let me know if
>> you would like more infos/pointers...
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Will Horn schrieb:
>>> In my application, I am using EMF as UI/presentation model for a rich
>>> client to a backend server. A simplified way to think about it is a
>>> tree view of tasks that reflect work the server is doing. I can see
>>> the tasks, start/stop them, and deploy new tasks to the server using a
>>> wizard.
>>>
>>> Since the communication with the server could be slow, it needs to run
>>> in a separate thread. So I need to be able to safely publish an
>>> EObject created on the UI thread to a background thread (e.g. for
>>> deployment), and safely update the UI model from a background thread
>>> (e.g. to reflect incoming updates).
>>>
>>> I think I can achieve this by carefully confining all reads and writes
>>> to the model to the UI thread. In the deployment case, I'd have to
>>> copy the EObject's fields into final/volatile variables for the
>>> background thread to use. From the other direction, I would use a
>>> form of Display.asyncExec to write to the model on the UI thread.
>>> I've also considered modifying the JET templates to make fields
>>> volatile (Java volatile, not EMF volatile). This doesn't work for
>>> collections, but it would simplify read-only access of simple fields.
>>>
>>> My question is: "Could EMF Transaction help me here?" It seems to be
>>> the standard answer for multi-threaded use cases, but I am not sure
>>> exactly how it addresses mine. My limited understanding of EMF
>>> Transaction (from the javadocs) is that it would enforce all model
>>> reads and writes to be done in a transaction and it uses a lock to
>>> ensure proper visibility across threads. Is this a better approach?
>>> My EObjects are really a sort of glorified JavaBeans that exist only
>>> in memory. I don't currently have a ResourceSet or an EditingDomain,
>>> and neither are necessary on the UI side.
>>>
>>> Thanks for any advice, or pointers to further documentation.
>>> -Will
>>>
>>>
>

--------------070004010809090008050906
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">
Will,<br>
<br>
Comments below...<br>
<br>
<br>
Will Horn schrieb:
<blockquote cite="mid:h4srr4$i0n$1@build.eclipse.org" type="cite">Hi
Eike,
<br>
<br>
Thanks for the response.&nbsp; Does CDO allow for a client side model
repository (maybe an in-memory one)?&nbsp; </blockquote>
Sure, you can embed the repository into your application or use local
TCP. Apart from that you can choose a backend store type, including
MEMStore.<br>
<br>
<blockquote cite="mid:h4srr4$i0n$1@build.eclipse.org" type="cite">I
noticed this wiki page which is empty
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Writing_Standalone_CDO_Applications">http://wiki.eclipse.org/Writing_Standalone_CDO_Applications</a> :o)
<br>
</blockquote>
Thx for the hint. I removed that link and info can be found in
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/User_Contributed_CDO_Documentation">http://wiki.eclipse.org/User_Contributed_CDO_Documentation</a><br>
<br>
<blockquote cite="mid:h4srr4$i0n$1@build.eclipse.org" type="cite"><br>
I actually have watched your recent webinar with Ed Merks.&nbsp; My
impression was that CDO was intended for keeping multiple clients
synchronized on a shared EMF model.</blockquote>
Well, that's one of several intentions ;-)<br>
A CDOSession can switch off this behaviour:<br>
<br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font
color="#000000">session.options</font><font color="#000000">()</font><font
color="#000000">.setPassiveUpdateEnabled</font><font color="#000000">(</font><font
color="#7f0055"><b>false</b></font><font color="#000000">)</font><font
color="#000000">;</font></code> </td>
<!-- end source code --> </tr>
</tbody>
</table>
</div>
<!-- = END of automatically generated HTML code = -->
<!-- ======================================================== --><br>
<blockquote cite="mid:h4srr4$i0n$1@build.eclipse.org" type="cite">&nbsp; In
my case the true model is on the server side and is not EMF.&nbsp; </blockquote>
Not EMF?? :P<br>
<br>
<blockquote cite="mid:h4srr4$i0n$1@build.eclipse.org" type="cite">My
EObjects are local to a single client.
<br>
</blockquote>
Soon we'll release our new EmbeddedSessionProtocol which makes usage of
local repositories even faster and less memory hungry. In the meantime
you could play with the JVMConnector for the Net4j session type.<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<blockquote cite="mid:h4srr4$i0n$1@build.eclipse.org" type="cite"><br>
-Will
<br>
<br>
<br>
"Eike Stepper" <a class="moz-txt-link-rfc2396E" href="mailto:stepper@esc-net.de">&lt;stepper@esc-net.de&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:h4rca9$o2b$2@build.eclipse.org">news:h4rca9$o2b$2@build.eclipse.org</a>...
<br>
<blockquote type="cite">Will,
<br>
<br>
I think the CDO Model Repository could help you with the mentioned
<br>
issues, and probably more. Not only CDO supports transactionality on
<br>
object level (EMF Transaction supports it on ResourceSet level and in
<br>
addition requires you to use commands to modify the model, IIRC). CDO
<br>
also shares model data among multiple transactions/views so that it's
<br>
rather cheap to create multiple transactions on the same session and
<br>
dedicate different threads to them. A proven pattern is to use a global
<br>
read-only view for all the UI lists and viewers and fork a transaction
<br>
in a background job for each modification action. Please let me know if
<br>
you would like more infos/pointers...
<br>
<br>
Cheers
<br>
/Eike
<br>
<br>
----
<br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>
<br>
<br>
<br>
<br>
Will Horn schrieb:
<br>
<blockquote type="cite">In my application, I am using EMF as
UI/presentation model for a rich
<br>
client to a backend server.&nbsp; A simplified way to think about it is a
<br>
tree view of tasks that reflect work the server is doing.&nbsp; I can see
<br>
the tasks, start/stop them, and deploy new tasks to the server using a
<br>
wizard.
<br>
<br>
Since the communication with the server could be slow, it needs to run
<br>
in a separate thread.&nbsp; So I need to be able to safely publish an
<br>
EObject created on the UI thread to a background thread (e.g. for
<br>
deployment), and safely update the UI model from a background thread
<br>
(e.g. to reflect incoming updates).
<br>
<br>
I think I can achieve this by carefully confining all reads and writes
<br>
to the model to the UI thread.&nbsp; In the deployment case, I'd have to
<br>
copy the EObject's fields into final/volatile variables for the
<br>
background thread to use.&nbsp; From the other direction, I would use a
<br>
form of Display.asyncExec to write to the model on the UI thread.
<br>
I've also considered modifying the JET templates to make fields
<br>
volatile (Java volatile, not EMF volatile).&nbsp; This doesn't work for
<br>
collections, but it would simplify read-only access of simple fields.
<br>
<br>
My question is: "Could EMF Transaction help me here?"&nbsp; It seems to be
<br>
the standard answer for multi-threaded use cases, but I am not sure
<br>
exactly how it addresses mine.&nbsp; My limited understanding of EMF
<br>
Transaction (from the javadocs) is that it would enforce all model
<br>
reads and writes to be done in a transaction and it uses a lock to
<br>
ensure proper visibility across threads. Is this a better approach?
<br>
My EObjects are really a sort of glorified JavaBeans that exist only
<br>
in memory.&nbsp; I don't currently have a ResourceSet or an EditingDomain,
<br>
and neither are necessary on the UI side.
<br>
<br>
Thanks for any advice, or pointers to further documentation.
<br>
-Will
<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>

--------------070004010809090008050906--


Previous Topic:XSDPackage nsuri, why not: http://www.w3.org/2001/XMLSchema
Next Topic:How to link a contentType to an existing editor?
Goto Forum:
  


Current Time: Wed Dec 11 23:03:23 GMT 2019

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

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

Back to the top