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