[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.newcomer] Re: Thread Safe EMF Collections 
Cameron,

Comments below.

Cameron Bateman wrote:
Also consider that modifying a list produces notifications and the handling of those notifications could invoke arbitrary and long running

This does raise a use case that may need support from within the framework: the ability for eAdapters to create a CopyOnWriteArrayList type structure. The EAdapterList implementation comes part way by calling ensureSafety on each modification to create the new copy on write, however ensureSafety itself is not thread-safe.
The new MinimalEObjectImpl uses a different implementation that involves an array that's never modified.

When you say this should be solved at the "application level", are there are any patterns for this?
Job and the Transaction framework.
I expect that CDO must do something under the covers, but a general approach would be good.
Except I don't believe there is a general approach that does not introduce the of deadlock.

One pattern I've seen used in WTP (although the thread-safety benefits are not fully exploited) is force writers to implement a Runnable rather than call setters directly. Using commands and a thread-safe command stack a la the EMF transaction framework is a similar pattern.
Yes, and in that case locking at the EMF level would be pointless or worse.

However, this leaves the question of what to do with readers.
Even readers can cause proxies to resolve...
It also opens the question of how to restrict the generated model so that users are forced to use commands to do writes.
It's not designed to be restricted in this way nor will it ever be the case. There are no panacea solutions or we'd have them already. 

Some questions:

1) Is there a way to generate a model with setters suppressed on the interface?
Yes, but reflectively you can still set the and of course for lists, the returned list is read/write.
When I use the suppressedSetVisibility genmodel annotation, this solves part of the problem by hiding the setter, however the reflective set is presumably still available off the interface since I'm still extending EObject.
Exactly and this is necessary for copying and deserialization.
I still want some of the EObject interface since I want add model listeners through eAdapters().add().

2) Is there a way to generate immutable value objects?
No because how would you populate them with values?
This seems trickier, since the factory methods don't take arguments (unless there's a way I haven't seen to generate this).
Nope. The factory creates bare new objects.
A useful pattern would be to somehow add arguments to the factory methods when setters are suppressed.
This presumes that you'd never need to create a cycle or mutual dependency.
Perhaps a type-safe composite of Setting delegates could be generated for each such EObject. 
More bloat!  Nooooo...

The transaction framework basically helps you find problematic code patterns by adding an adapter that ensures, whenever it sees a change, like a proxy resolve or other modification, that it's happening in the context of a transaction... 


Thanks,

Cameron