Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: Chuck Hill <email@hidden>
- Date: Mon, 14 Nov 2005 12:59:30 -0800
On Nov 14, 2005, at 12:06 PM, Dov Rosenberg wrote:
We use shared editing contexts for a portion of our application
that does read only operations. For the most part things work as
expected. Lately we have been experiencing some slow downs that
appear to point to issues within our shared editing contexts. Below
is a thread dump that shows the thread lock and the associated
relevant code.
Couple of Questions:
Our app is typically deployed as a Servlet and is inherently multi-
threaded as a result. The servlet containers assume that the apps
that are running are multi-threaded. Unless we deploy inside a
servlet cluster, we typically only have one instance of our app
running in the container. It appears that no matter how busy the
app is only one DB connection is ever spawned. Obviously that would
present a potential bottleneck to performance. I have seen some
reference in Project Wonder to some classes that will spawn
multiple DB connections. Has anyone used these? Are they stable?
How do sharededitingcontexts play with those classes?
I don't think those work like you intend. I think you are thinking
of DatabaseChannelNeededNotification in EODatabaseContext. "This
nofification is broadcast whenever an EODatabaseContext is asked to
perform an object store operation, and it does not have an available
databaseChannel. Subscribers can create a new channel and add it to
the databaseContext at this time."
This is only used within the thread that has the EOF stack locked and
only if the process causes fetches to be triggered while another DB
transaction is in progress. e.g. rarely.
In general, to get multi-threaded DB access you need to create
multiple EOF stacks.
Are SharedEditingContexts multi-threaded? Can they support our
scenario in item 1?
See David's answer. My opinion on the Shared EC is to avoid it like
the plague if you plan on concurrency.
Chuck
We recently made some changes to try to fix this problem. We set
the sharededitingcontext = null anywhere we created a new editing
context doing something like:
public static EOEditingContext actionEditingContext()
{ EOEditingContext ec = new EOEditingContext();
ec.setSharedEditingContext(null); return ec; }
The offending code looks like:
public static NSArray userWithIDInSite(EOEditingContext ec, Site
site, String login) throws CVDatabaseException { NSArray
userList = null; NSMutableArray args = new NSMutableArray
(); try { args.addObject(login);
args.addObject(site); userList =
EOUtilities.objectsWithQualifierFormat(ec, "UserInformation",
"login = %@ AND ownerSite = %@", args); } catch (Throwable
thrownCondition) { ... } return
userList; }
This code is called using the shared editingcontext returned from
EOSharedEditingContext.defaultSharedEditingContext();
Thread dump:
"ExecuteThread: '4' for queue: 'weblogic.kernel.Default'" daemon
prio=5 tid=0x08ca4e08 nid=0x9d8 in Object.wait() [9f2f000..9f2fdb8]
at java.lang.Object.wait(Native Method)
- waiting on <0x2f64a1e8> (a
com.webobjects.foundation.NSMultiReaderLock$ConditionLock)
at java.lang.Object.wait(Object.java:429)
at com.webobjects.foundation.NSMultiReaderLock
$ConditionLock.await(NSMultiReaderLock.java:506)
- locked <0x2f64a1e8> (a
com.webobjects.foundation.NSMultiReaderLock$ConditionLock)
at com.webobjects.foundation.NSMultiReaderLock._lockForWriting
(NSMultiReaderLock.java:204)
at com.webobjects.foundation.NSMultiReaderLock.lockForWriting
(NSMultiReaderLock.java:165)
at com.webobjects.eocontrol.EOSharedEditingContext.lock
(EOSharedEditingContext.java:700)
at
com.webobjects.eocontrol.EOSharedEditingContext.objectsWithFetchSpecif
ication(EOSharedEditingContext.java:347)
at
com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecificatio
n(EOEditingContext.java:4461)
at
com.webobjects.eoaccess.EOUtilities.objectsWithQualifierFormat
(EOUtilities.java:145)
at com.inquira.model.UserInformation.userWithIDInSite(Unknown
Source)
at com.inquira.client.tags.AutoLoginTag.startTagHandler(Unknown
Source)
....
Any thoughts or ideas are appreciated.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
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