You don't have to lock immediately upon making an EC, rather you have to lock around anything that touches the EC. That includes accessing attributes and relationships of EO's, modifying EOs in any way, and committing your in-memory transaction.
the dbcontext lock only protects the dbcontext, it doesn't protect your other threads' EC's, which will be receiving change notifications asynchronously while you're trying to use the EOs in them. you're basically just asking for nasty problems. ms On May 1, 2010, at 4:19 PM, Farrukh Ijaz wrote: > It looks like one has to have faith that EC must be locked/unlocked in any > case. Referring the following post... > > http://www.mail-archive.com/[email protected]/msg21704.html > > If EOEditingContext puts lock on DBContext somewhere inside saveChanges(), > and after success/failure of the operation unlocks DBContext then I'm still > confused why to hold a lock right after creating / obtaining EOEditingContext. > > Can someone please explain this "why", instead of using a bullet-proof > EOEditingContext lock/unlock strategy? If I understand the reason behind, it > would be easy to fix some of the issues we've been facing in the past. > Actually I'm tweaking some applications where I've seen EC without lock / > unlock retrieving data, specifically when the saveChanges() is being > performed, the EC is locked, unlocked, disposed and then nullified. > > Thanks in advance, > > Farrukh > > On 2010-05-01, at 8:22 PM, Farrukh Ijaz wrote: > >> Thank you very much sir. Now I won't forget the lesson for the rest of my >> life. :) >> >> Another question, is it safe not to lock EC if I'm sure I'm not gonna modify >> the objects fetched using that EC the rest of the Application Life Cycle? >> >> Farrukh >> >> On 2010-05-01, at 8:11 PM, Chuck Hill wrote: >> >>> >>> On May 1, 2010, at 10:01 AM, Farrukh Ijaz wrote: >>> >>>> Is it legal to perform saveChanges/revert on EOEditingContext in a >>>> traditional JDBC transaction commit/rollback style? >>>> >>>> EOEditingContext ec = // Got EOEditingContext from Somewhere... >>>> // ec is not locked... >>> >>> Find gun. >>> Shoot self in head. >>> Don't worry about rest of code. >>> >>> This is so very not safe. An unlocked editing context is a bomb. >>> >>> >>>> // did a lot of fetches... >>>> // modified some objects fetched using this ec... >>>> try { >>>> ec.lock(); >>>> ec.saveChanges(); >>>> } catch(Exception ex) { >>>> throw ex; >>>> } finally { >>>> ec.revert(); >>>> ec.unlock(); >>>> } >>>> >>>> What can be the potential problem in the above approach? Sorry if I sound >>>> stupid here but this is quite a good practice in JDBC style coding :) >>> >>> >>> This is not JDBC. :-) An editing context is not a database transaction. >>> >>> One of these two patterns is the usual practice: >>> >>> // ec is locked and has been before fetching, or inspecting or modifying >>> objects >>> >>> try { >>> ec.saveChanges(); >>> } catch(EOGeneralAdaptorException e) { >>> // Deal with exception >>> // prepare to present exception to user >>> } >>> } catch(EOValidationException e) { >>> // Deal with exception >>> // prepare to present exception to user >>> } >>> >>> >>> If you really want to reverse all changes rather than try to correct the >>> problem: >>> try { >>> ec.saveChanges(); >>> } finally { >>> ec.revert(); >>> } >>> >>> >>> Chuck >>> >>> >>> >>> -- >>> Chuck Hill Senior Consultant / VP Development >>> >>> Practical WebObjects - for developers who want to increase their overall >>> knowledge of WebObjects or who are trying to solve specific problems. >>> http://www.global-village.net/products/practical_webobjects >>> >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> 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/farrukh.ijaz%40fuegodigitalmedia.com >> >> This email sent to [email protected] > > _______________________________________________ > 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/mschrag%40pobox.com > > This email sent to [email protected] _______________________________________________ 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]
