Re: EOEditingContext Lock/Unlock best practice?
Re: EOEditingContext Lock/Unlock best practice?
- Subject: Re: EOEditingContext Lock/Unlock best practice?
- From: shravan kumar <email@hidden>
- Date: Wed, 8 Apr 2009 10:13:51 -0700 (PDT)
| Thanks for your quick response Guido!!!
I will just need to evaluate your solution with our team and then act on it accordingly.
How about if I use session's defaultEditingContext and where needed I will just revert the EC, if I do not need to persist the objects in the EC? Most of our app uses session's defaultEditingContext. --- On Wed, 4/8/09, Guido Neitzer <email@hidden> wrote:
From: Guido Neitzer <email@hidden>
Subject: Re: EOEditingContext Lock/Unlock best practice?
To: "shravan kumar" <email@hidden>
Cc: email@hidden
Date: Wednesday, April 8, 2009, 10:04 PM
On 7. Apr. 2009, at 23:43
, shravan kumar wrote:
> For setting the locking property mentioned, does my app need to extend ERXApplication? currently my app is very loosely coupled to Project Wonder i.e., we use different API's from Project Wonder as needed.
You need to extend from ERXApplication, ERXSession and use ERXEC exclusively with:
ERXEC.newEditingContext()
whenever you create a new editing context. The session editing context is done for you. All editing contexts are locked / unlocked for you.
> Moreover, after setting this property should I lock & unlock EOEditingContext in R-R loop or while fetching, saving, or modifying any EO object.
No. It happens automagically.
Just make sure you have no
new EOEditingContext()
calls anywhere in your call, replace all of those with the method mentioned above to get an ERXEC.
cug
|
_______________________________________________
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