Re: Idea: EOEditingContextGroup

At 08:21 PM 12/18/2002 +0100, David Teran wrote:
>No, only until you call dispose and then remove it from the collection ;-)

So in your conception, your code would explicitly get rid of the peer EC 
when it was done with it?  Rather than count on Java garbage collection to 
just take care of it when it wasn't being used anymore, as Java often lets 
us get away with doing. I'm asking how you conceive of doing this in your 
actual code.

And you'd need to make sure not to dispose/remove-from-collection it while 
it still has a lock() out. Unless dispose() takes care of that. It very 
well might, actually. But that shouldn't be too too hard in any event.


>I think pooling will be the next step and it could be based on the 
>multieof framework which works pretty fine. I do not see any problem 
>unless one does not dispose the ec and remove it from the collection, but 
>at least disposing is also important for nested ecs afaik. My biggest 
>concern is using a custom ec which means its not a good framework.

Yeah; I'm not sure if pooling would work equally acceptable for my own 
nested (rather than peer) ecs. I'd definitely have to make sure that the EC 
got 'reset' to be a virgin EC in between uses---I'm used to leaving unsaved 
changes in my nested ECs that I'll never change, and just letting the 
nested EC get garbage collected.

Harder is the problem that, with pooling or with an explicit 
dispose-and-remove-from-collection, it's up to my code to know when it's 
done with the EC and do something about it (tell the pool that it's 
available again; dispose-and-remove).  My design makes this a big pain. I 
often use one 'local' (peer or nested) EC for a single component instance. 
When are we done with this EC?  Well, whenever we're done with the 
component instance. When are we done with the component instance?  Simply 
whenever the component instance goes out of scope and is available for 
GC---when it's no longer in the page cache, but ALSO no longer held in a 
reference of any other reachable object. I frequently use the later---store 
WOComponent instances in references of other objects.

So I'm not sure where I'd put the code that released the EC, that said, 
okay, we're done with it now. There's no good way to determine this.

I'm curious as to your design, and how/when you will determine that the EC 
can now be disposed or returned to the pool, or whatever.

00Jonathan


>regards, David
>
>
>>At 07:30 PM 12/18/2002 +0100, David Teran wrote:
>>>Hi,
>>>
>>>i just had a short discussion with wojtek about nested and peer ec. I 
>>>had the following idea to automatically lock and unlock peer ecs:
>>>
>>>1) A EOEditingContext subclass overrides lock and unlock
>>>2) set this ec to be the default ec from the session
>>>3) session should know ever peer ec (register the ec in an array / 
>>>collection)
>>>4) when session sends lock and unlock to its defaults ec the default ec 
>>>will either post a synchron notification or just tell the session back 
>>>to lock / unlock every peer ec in the sessions array / >> collection
>>>
>>>Does someone see any problem with such a feature except that one uses a 
>>>custom ec? Just wrote the concept things down in the mail but i did not 
>>>test the code. Of course some things are still missing, this is just a 
>>>concept and not a working class.
>>>
>>>regards david
>>>
>>>public class C9EditingContext extends EOEditingContext {
>>>
>>>   public C9EditingContext() {
>>>     super();
>>>    }
>>>
>>>public void lock() {
>>>   super.lock();
>>>   //post synchron lock notification here
>>>}
>>>
>>>public void unlock() {
>>>   super.unlock();
>>>   //post the synchron unlock notification here
>>>}
>>>}
>>>
>>>public class Session extends WOSession {
>>>
>>>  private NSMutableArray ecs = new NSMutableArray();
>>>
>>>  public Session() {
>>>   super();
>>>   setDefaultEditingContext(new C9EditingContext());
>>>}
>>>
>>>//method gets called when the locked notification is received
>>>public void lockedEc() {
>>>for (Enumeration e = ecs.objectEnumerator(); e.hasMoreElements();) {
>>>   EOEditingContext ec = (EOEditingContext)e.nextElement();
>>>   ec.lock();
>>>}
>>>}
>>>
>>>//method gets called when the unlocked notification is received
>>>public void unlockedEc() {
>>>for (Enumeration e = ecs.objectEnumerator(); e.hasMoreElements();) {
>>>   EOEditingContext ec = (EOEditingContext)e.nextElement();
>>>   ec.unlock();
>>>}
>>>}
>>>
>>>On Saturday, Jul 6, 2002, at 03:04 Europe/Berlin, Max Muller wrote:
>>>
>>>>Hi,
>>>>         One of the legacy issues that EOF has maintained since being 
>>>> built solely for the desktop is the notion of always propagating 
>>>> changes to all of the existing editing contexts for a given 
>>>> objectstore coordinator. This leads to the behavior that if two people 
>>>> are editing the same eo in two different sessions then they could see 
>>>> each others changes if they are on the same app instance and not see 
>>>> each others changes if they are not on the same app instance. By "see 
>>>> each others changes" I mean that if one successfully saves then the 
>>>> changes will be propagated into the others editing context. This 
>>>> behavior is not ideal as multiple instances can cause optimistic 
>>>> locking failures. One solution is to use a delegate and disable all 
>>>> propagation of changes between editing contexts, this however sucks 
>>>> because then you can't use peer contexts to edit or create eos. 
>>>> Another solution is to give each session it's own complete EOF stack, 
>>>> this one also sucks because in doing this you add *way* too much 
>>>> overhead which will eat memory like you wouldn't believe if you had 
>>>> say 1,000 sessions active. So how about adding an 
>>>> EOEditingContextGroup that you could then use to control the 
>>>> propagation of changes to only those editing contexts within the 
>>>> group? This way each session would have it's own ec group which the 
>>>> defaultEditingContext would be a member of, new peer contexts could 
>>>> also be added to the group so that changes occurring in those contexts 
>>>> would propagate to the default ec.
>>>>
>>>>         The only difficult aspect would be "knowing" if an optimistic 
>>>> locking failure occurred within the same application. Right now all of 
>>>> the snapshots are held at the database context layer. Once one session 
>>>> had updated an object (say setting Person's firstName to "Scott") then 
>>>> the snapshot reflects this new value. However if those changes have 
>>>> not been propagated to another session that has changes to the same eo 
>>>> then by default if they attempt to save and *are* on the same instance 
>>>> the save will go through, if they are not on the same instance the 
>>>> save will fail (assuming locking). What I am wondering is how to make 
>>>> sure that the save within the same application fails as well. One 
>>>> approach would be for the eo itself to "know" it's committed snapshot 
>>>> and then the ec could compare the eo's committed snapshot against the 
>>>> databasecontext's snapshot for the object and potentially throw the 
>>>> optimistic exception. I don't think that this is the best approach, 
>>>> anyone else have any thoughts? How would you implement this (or not 
>>>> ;)? Is the idea of ec groups a good one?
>>>>
>>>>Regards,
>>>>         Max
>>>>
>>>>ps -  As a side note I would also like to provide an optimistic locking 
>>>>resolver interface that could be registered on a per entity basis that 
>>>>could intercede if a locking failure occurred and potentially prevent 
>>>>an actual exception from being thrown. In other words being able to use 
>>>>different policies for locking failures depending on the business case 
>>>>and also being able to throw your own type of locking exception.
>>>>
>>>>
>>>>_______________________________________________
>>>>EOF mailing list
>>>>[email protected]
>>>>http://www.omnigroup.com/mailman/listinfo/eof
>>>---
>>>cluster9, David Teran
>>>
>>>Juedenstrasse 13
>>>37073 Goettingen
>>>Germany
>>>
>>>Mail: [email protected]
>>>Phone: +49 (0) 551 48 83 077
>>>Fax: +49 (0) 551 48 83 079
>>>
>>>_______________________________________________
>>>EOF mailing list
>>>[email protected]
>>>http://www.omnigroup.com/mailman/listinfo/eof
>>
>---
>cluster9, David Teran
>
>Juedenstrasse 13
>37073 Goettingen
>Germany
>
>Mail: [email protected]
>Phone: +49 (0) 551 48 83 077
>Fax: +49 (0) 551 48 83 079