Thanks Mike for clarifying things. Now it makes sense to me why and where we need to lock / unlock EC.
Nobody wants to deal with nasty problems but if they are there, one must know the root cause. Farrukh On 2010-05-01, at 11:30 PM, Mike Schrag wrote: > 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/webobjects-dev@lists.apple.com/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 (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/farrukh.ijaz%40fuegodigitalmedia.com >>> >>> This email sent to farrukh.i...@fuegodigitalmedia.com >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >> >> This email sent to msch...@pobox.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/farrukh.ijaz%40fuegodigitalmedia.com > > This email sent to farrukh.i...@fuegodigitalmedia.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
