Re: Idea: EOEditingContextGroup

> 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.
>
as you say below, you should always dispose the ec so you would not 
rely on gc.

> 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.
>
thats simple: just call unlock, dispose, and then remove it from the 
collection. in sessions sleep the ec is not in the collection anymore 
and will not receive any unlock message.

> 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.
pooling does not make sense for nested ecs: with pooling i mean 
different EOF stacks to enable more multithreading.

>
> 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.
>
it will of course affect your app design and not everything is solved. 
It was just an idea how to get rid of the lock and unlock things.

> 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.
>
I will implement something like this in a upcoming project and when its 
finished and working i will post a message (and also if i have 
questions or other things to discuss ;-)

regards, david


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