On 11/8/07 7:00 AM, Patrick Middleton wrote:
My dealings with multiple ECs in WO4.5.1 were -- indeed, are -- mostly to do with either nested ECs or ECs being worked in separate threads. I found when doing something time consuming, it was necessary to do it in a separate thread, and it was best to use a separate EC which I could lock and unlock as needed to avoid risking have the session's default EC be locked by a detached thread at a time when the session wanted to lock it because of servicing a page request.Then I'm not crazy! I was wondering if there was just something I wasn't understanding.Yes, locking the EC will cause it to create a new NSAutoreleasePool, and yes, there are various things you can do such as -reset that will cuase the EC to lock itself. NSAutoreleasePools are stacked, so there is lots of scope to be bitten, and the best solution I can see is unlock the peer ECs in the reverse order to which they were locked, as described.
NSAutoreleasePools are stacked per thread (and it says so in the class reference documentation). If you had each EC in a different thread, then you wouldn't encounter the problem you have -- rather, a whole bunch of different problems instead. I found that getting editing contexts to deallocate cleanly was a severe pain, because EOF hacks -dealloc for objects managed by ECs, and I was frequently hitting problems where something that was doing a pretend-to-deallocate-now-but-really-deallocate-later because of EOF was causing crashes when it actually did deallocate, because it had references to other parts of the EOF object graph which had already genuinely deallocated.This fits the intermittent errors that I'm seeing and makes a lot of sense now. Crud.
Although I can't find the bit of documentation that says so (ie, it's not in the class reference documentation), it's my understanding that when an NSAutoreleasePool is released, any child NSAutoreleasePools -- necessarily stacked -- will also be released, and this would be a severe nuisance.
Yes, this is exactly what happens.
Having reviewed Jonathan's original code, if we are working solely with peer ECs, do we really need MultiECLockManager? If all I needed was some convenience for ensuring that when I was finished, all ECs of interest were sent the right number of -unlock messages, I'd refactor this (or write something else) so that each editing context had its own lock count, and I could lock or unlock any managed EC (or query its lock count) via my manager object. That way, I could unlock ECs when they no longer needed to be locked ... except if I lock A then lock B, I cannot let the lock count for A fall to 0 until the lock count for B has fallen to 0 because of the stacked NSAutoreleasePool problem. Hmmm. This whole matter would be much simpler if one could refactor one's code to ensure that a maximum of 1 peer editing contexts was ever concurrently locked.I've started down the exact same train of thought. While debugging and trying to figure out the whole autorelease pool stack thing, I did write a category for EOEditingContext that exposed some ivars, namely lockCount and lockPool. I could use that to track the lock count, at least.
Thank you for your response! I really thought I had to be missing something here, but at least it is nice to know that I'm not.
-- ------------------------------------- Dana Kashubeck Systems Manager Riemer Reporting Service Inc. http://www.riemer.com Phone: 440-835-2477 x. 125 Fax: 440-835-4594 -------------------------------------
begin:vcard fn:Dana Kashubeck n:Kashubeck;Dana org:Riemer Reporting Service, Inc.;MIS adr:Suite 100;;24600 Detroit Road;Westlake;Ohio;44135;United States of America email;internet:[EMAIL PROTECTED] title:Systems Manager tel;work:440-835-2477 ext. 125 tel;fax:440-835-4594 x-mozilla-html:FALSE url:http://www.riemer.com version:2.1 end:vcard
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
