[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:
The new MinimalEObjectImpl uses a different implementation that involves an array that's never modified.

So if a listener wants to deregister itself in response to being notified, does it throw an exception?
No. That would be bad, wouldn't it? The notification proceeds with the original adapter array as before.

Yes, and in that case locking at the EMF level would be pointless or worse.

I agree with you. I'm looking for an best practice that I can follow for generated models. EMF Transactions appears to provide a big piece of the puzzle.
Yep.

Even readers can cause proxies to resolve...

Even simpler than that: memory model consistency would require you to synchronize readers if other threads are doing sets.
If a thread is making modifications, another thread doing reading my well see an inconsistent state even if they don't directly stomp on each other. I.e., the indexOf(x) delete at that index example.
I see the EMFT seems to support reader transactions.
Definitely.
One thing that appears to be missing (although I have admittedly not done an exhaustive search) is a way to transactionalize reads in an EMF binding context.
That may well be. No one has done a data binding implementation for the transaction component. Want to get involve? The only committer, Christian, is giving up his status, so we need volunteers...

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.

Fine, but if I'm using EMFT to protect my model access, suppressing my user's ability to access the same memory through another route that isn't thread safe is an important option.
Performance is an important option too. :-P As you can imagine, I've been around this block more than a few times and something sound never seems to surface.
What about a pattern similar to the CDO eStore, where you can create objects on the fly put as soon as they are owned by a transactional resource, your options become more restrictive, since at that frontier you are declaring them to be "shared"?
It sounds interesting. Want to get involved?

Yes, but reflectively you can still set the and of course for lists, the returned list is read/write.
..
Exactly and this is necessary for copying and deserialization.

Good point. What about the idea of using a working copy/immutable copy pattern, where an "immutable" interface is generated and then the normal "mutable" one sub-interfaces it?
One could attach and adapter that throws an exception for any changes. It could even be a ChangeRecorder that undoes the change. The question is whether you are looking for actual security or just detecting problems so they can be fixed/avoided? Security is a very hard issue.
The factory could return the "mutable" one, which is just how it works today and then a narrowing cast to the immutable one can be returned to users further down the line that can be passed to the transaction framework but wouldn't be easy to modify (i.e. you'd have to explicitly downcast, at which point you are on your own)?
Sounds complicated doesn't it. Consider why Collections don't have a read-only API and a read-write API?

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...

But if someone knows that they simply want to create immutable value objects? Is there a modelling principle here that immutable value objects are bad?
Nope. Based on the List analog, it should be sufficient that an attempt to change it will throw and exception rather that that the API prevents the attempt...

The transaction framework basically helps you find problematic code patterns by adding an adapter that ensures, whenever it sees a change,

That is very helpful. Of course, the more I can use the compiler to do my dirty work, the better :).
The problem is the proliferation of APIs... I'm pretty sure that's why the collection classes avoided this approach... 



Thanks,

Cameron