Hi Dov,
On 18/11/2005, at 1:35 PM, Dov Rosenberg wrote:
For the SEC we do things like:
sec.objectsForFetchSpecification(...)
Which appears to be causing our locking problem under load.
According to what I have learned - objectsForFetchSpecification()
will cause
the SEC to get a write lock in order to update its state. It can
not get a
write lock until all of the read locks have been released.
Under load conditions there are readers all the time and the write
lock can
not be obtained.
Could you perhaps create a subclass of EOSharedEditingContext,
setting it as the default SEC, and
- implement a readers-writer locking process that will queue readers
if a writer is in the queue so that writer(s) don't get starved.
- i.e., when the change notification comes through you have a writer...
It seems that calling objectsForFetchSpecification() to either
fetch data
into the shared editing context or to refresh it too often is a bad
thing.
When multiple threads are trying to do the same operation - the EOF
deadlock
occurs.
deadlock or writer starvation? i.e., readers keep on functioning, yes?
Can anyone think of a reasonable strategy? Besides dumping EOF and
using
JDBC.
The above wouldn't take too much effort and would give you control
over the reader/writer starvation problems without having to change
much else I would think. Hmm.. I might look into that for myself...
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
