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:19:11 +0300
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