|
|
| Re: Parallelized execution of OCL queries [message #666268 is a reply to message #666186] |
Tue, 19 April 2011 16:27   |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Chris
Axel's suggestions sem like your best bet. The OCL facade seems to only
allow a single EvaluationEnvironment and I feel your problem should be
soluble with one OCL, one EnironmentFactory, one Environment, and
multiple EvaluationEnvironments. If you use your own EnvironmentFactory
so that you can keep a reference to it, you may be able to get away with
a distinct nested EvaluattionEnvironment per query. But the
threadsafe-ness of the OCL classes is untested, and I'm not certain that
you will find the underlying EMF usage threadsafe in the absence of EMF
Transaction support.
Thanks for the prod. I've raised
https://bugs.eclipse.org/bugs/show_bug.cgi?id=343286 to take this and
the Java 7 multi-threading capabilities seriously (for Juno).
Regards
Ed Willink
On 19/04/2011 13:32, Axel Uhl wrote:
> Chris,
>
> off the top of my head, I suggest first parsing the expression, using
> e.g., OCL.newInstance().createOCLHelper().createQuery(String). You can
> then create multiple OCL objects using OCL.newInstance() and evaluate
> the single OCLExpression using OCL.evaluate(OCLExpression). This
> should also work in parallel as the different OCL objects will create
> their own, independent evaluation environments.
>
> Best,
> -- Axel
|
|
|
|
|
|
|
|
| Re: Parallelized execution of OCL queries [message #667344 is a reply to message #666299] |
Thu, 28 April 2011 08:53 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Ed
An Ecore model might be expected to be read-only threadsafe, but
anything that involves a cache offers an opportunity for problems. Even
if a race is ultimately resolved by whoever wins, there is a risk that
the competitors get to use their competing contributions, one of which
will probably have a broken eContainer() chain. For a race hierarchy,
not all races may be won by the same competitor so the winners may not
form a consistent set of objects.
EMF is much more than read only models, so I suspect that a review is
needed at least to establish the boundary at which EMF is intrinsically
threadsafe, and what corrections may be necessary to ensure that all
functionality is threadsafe when supervised by EMF Transactions.
No methods in ResourceSetImpl or EcorePlugin are synchronized, so there
are certainly opportunities for unthinking abuse.
Regards
Ed
On 19/04/2011 20:42, Ed Merks wrote:
> Axel,
>
> In general an Ecore model should be read-only thread safe so I would
> hope these aspects are as well. If not, we should look at addressing
> that. At a glance it looks like they'd be safe although there
> definitely could be race conditions, it doesn't look like it would
> matter who wins the race.
>
>
> Axel Uhl wrote:
>> Please also note that the delegates stuff and internal caching of
>> operation and property bodies is most likely not thread-safe yet either.
|
|
|
Powered by
FUDForum. Page generated in 0.03202 seconds
] 
Search
Help
Register
Login
Home
