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?
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. 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. 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. 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
