Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: Dov Rosenberg <email@hidden>
- Date: Mon, 14 Nov 2005 16:02:44 -0500
- Thread-topic: SharedEditingContext Write Locks?
Title: Re: SharedEditingContext Write Locks?
Hmmm, I kind of suspected that was the case. The whole reason we were using SEC at all was to help performance under load. It doesn’t make sense to have to re-retrieve a lot of the info that is read only for every session that connects up. We tried caching Eos which failed miserably and have resorted to storing their primary keys and fetching as needed. We do have a NSMutableDictionary that we use as an EO cache (primary key is the key). We get a localInstanceofObject before doing anything with it.
On 11/14/05 3:21 PM, "David Teran" <email@hidden> wrote:
EOSEC is known to be hard to use. Its very likely that you will have EOF deadlocks, which is what you see below. AFAIK the only way to use it without deadlocks is:
load the desired eos at startup and make sure they will -nevernever- change no matter if you fault them into another ec, set sec from this ec to null and change the eo there. Do not change them -anywhere-.
regards, David
Am 14.11.2005 um 21:06 schrieb Dov Rosenberg:
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?
- Are SharedEditingContexts multi-threaded? Can they support our scenario in item 1?
-
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.objectsWithFetchSpecification(EOSharedEditingContext.java:347)
at com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(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:
This email sent to email@hidden
_______________________________________________
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