Re: saveChanges/revert on EOEditingContext
Re: saveChanges/revert on EOEditingContext
- Subject: Re: saveChanges/revert on EOEditingContext
- From: Farrukh Ijaz <email@hidden>
- Date: Sat, 1 May 2010 23:41:50 +0300
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/email@hidden/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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden