David, why don't you cite an your wonderful article about EC? :) http://davidleber.net/?p=322
2009/6/22 David LeBer <dle...@codeferous.com> > > On 22-Jun-09, at 7:58 AM, Vicky C. Miller wrote: > > Guido: >> >> Thanks for your input. One of the references you cited looks like Project >> Wonder based. These are the possible solutions we came up with. Do you >> recommend we go with the Project Wonder solution? >> > > Everyone's code is different, but I am a Project Wonder convert and > wouldn't build an app without it. > > Solution 1: Explicitly handling locking and unlocking of EOEditing Context >> >> Adding lock() and unlock() statements where ever we access data, fetch >> data, >> insert data and delete data using Editing Context. Till now in our SOLAR >> code lock() and unlock() features are not used for Editing Context. For >> using this, we have to apply this feature to the whole application code. >> This solution is more error prone and may result in errors during >> application usage. >> >> Time required for implementing this solution : Around 25 to 30 working >> days, >> as we have to apply this feature to whole application for maintaining >> consistency. >> >> Solution 2: Using Project Wonder Framework >> >> Adding Project Wonder framework to our SOLAR application. Adding this >> frame >> work requires change in design of application. For example, we have to >> subclass Application class from ERXApplication instead of WOApplication. >> Similarly Session class from ERXSession instead of ERXSession. >> >> We have to change all the references of EOEditingContext to the one >> compatible with Project Wonder framework. >> > > To clarify, you do not need to change the references to EOEditingContext. > > You ONLY need to replace any call to "new EOEditingContext()" with > "ERXEC.newEditingContext()" > > So: > > EOEditingContext myEc = new EOEditingContext(); > > Becomes: > > EOEditingContext myEc = ERXEC.newEditingContext(); > > Using of Project Wonder framework will automatically handles the lock() >> and >> unlock() features of the editing context. >> >> Time required for implementing this solution : Around 15 to 20 days. >> > > Really? > > Solution 3: Using Session's default Editing Context >> >> Using Session's default Editing Context where ever we find thisproblem >> with >> locking. Session's default Editing Context will take care of locking and >> unlocking of editing context automatically. >> >> For example, the recursive locking error that was reported in the attached >> dump file is in method "configureToolsDisplay()" of Session's class. So, >> we >> will use Session's default Editing Context in this method instead of >> already >> used EOEditingContext. >> > > Also remember that the Session defaultEditingContext is global for the > session. So you will often have cleanup tasks necessary to prevent unwanted > changes from cluttering up the default EC. > > Time required for implementing this solution : As we are try to fix the >> problems whenever it uncovers, it will take around 1 to 2 days for >> resolving >> each uncovered issue. >> >> vm >> -----Original Message----- >> From: Guido Neitzer [mailto:guido.neit...@gmail.com] >> Sent: Monday, June 22, 2009 12:44 AM >> To: vcmil...@cssg.com >> Cc: webobjects-deploy@lists.apple.com >> Subject: Re: Excessive WebObjects Locks >> >> This basically answers the question itself. You must (MUST MUST MUST) >> lock / unlock your editing contexts! Only the defaultEditingContext is >> locked / unlocked for you! >> >> Look into the autolocking features of MultiECLockManager [1] or ERXEC >> [2] if you don't want to bother locking your ECs. Don't try locking >> yourself. You will most probably fail as there are many cases you >> won't find if you had to ask the question below. Go with the available >> options and REALLY use them. Your life will be miserable without! >> >> Guido >> >> [1] http://codeferous.com/files/MultiECLockManager.java >> [2] http://wiki.objectstyle.org/confluence/display/WONDER/Tutorials >> >> >> On 21. Jun. 2009, at 20:45 , Vicky C. Miller wrote: >> >> We are not using EOSharedEditingContext anywhere in our application. >>> We are >>> using following Editing Contexts in our application : >>> >>> 1. At some places of our application we are using session's >>> defaultEditingContext() >>> 2. At some places of our application we are creating a new >>> EOEditingContext >>> where ever it is required. >>> >>> vm >>> -----Original Message----- >>> From: Travis Britt [mailto:tbr...@phigment.org] >>> Sent: Saturday, June 20, 2009 11:01 AM >>> To: webobjects-deploy@lists.apple.com >>> Cc: vcmil...@cssg.com >>> Subject: Re: Excessive WebObjects Locks >>> >>> Are you using EOSharedEditingContext anywhere? >>> >>> tb >>> >>> On Jun 19, 2009, at 6:45 PM, Vicky C. Miller wrote: >>> >>>> Our issue is occurring where the code uses EOEditingContext and other >>>> objects in the WebObjects API that acquire a >>>> com.webobjects.foundation.NSRecursiveLock. >>>> >>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-deploy mailing list (Webobjects- >>> dep...@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> >>> >> http://lists.apple.com/mailman/options/webobjects-deploy/guido.neitzer%40gma >> il.com >> >>> >>> This email sent to guido.neit...@gmail.com >>> >> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> >> http://lists.apple.com/mailman/options/webobjects-deploy/dleber%40codeferous.com >> >> This email sent to dle...@codeferous.com >> > > ;david > > -- > David LeBer > Codeferous Software > 'co-def-er-ous' adj. Literally 'code-bearing' > site: http://codeferous.com > blog: http://davidleber.net > profile: http://www.linkedin.com/in/davidleber > twitter: http://twitter.com/rebeld > -- > Toronto Area Cocoa / WebObjects developers group: > http://tacow.org > > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/webobjects-deploy/federico.cattozzi%40gmail.com > > This email sent to federico.catto...@gmail.com > -- Federico Cattozzi gmail/gtalk/MSN: federico.catto...@gmail.com skype: federico_cattozzi yahoo: federico.cattozzi AIM: federicocattozzi ICQ: 153467830
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com This email sent to arch...@mail-archive.com
