[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.newcomer] Re: Thread Safe EMF Collections
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?

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.

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. I see the EMFT seems to support reader transactions. 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.

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

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? 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)?

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?

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


Thanks,

Cameron