On 15/12/2008, at 1:16 PM, Dov Rosenberg wrote:
Hadn't really noticed the lockForReading() and unlockForReading()
methods.
Perhaps that could stop the objects from mutating while we are
trying to
access them under load.
Worth a try I would suggest. The api suggests:
"In multithreaded applications, shared objects can be used safely by
many threads at once. Shared editing contexts use NSMultiReaderLocks
to maintain thread safety. The methods objectsWithFetchSpecification
bindObjectsWithFetchSpecification, faultForGlobalID, and
objectForGlobalID are thread safe, but the context must be locked
before using any other shared context API."
Looking thru the code it seems that various methods
like objectsWithFetchSpecification() etc all do a lock() and unlock()
already. If our methods were synchronized that make these calls
would that
accomplish the same thing?
I think it's a question of how fine-grained you want your locking.
i.e. allowing EOF to auto-lock via objectsWithFetchSpecification for
example or heading towards a more block-based lock with try/catch. The
question is what's happening with the database context.
I can only suggest pinging Pierre for more.
The memory usage is pretty good. The app behaves very well under
load -
regular garbage collection rhythms.
None of our Entities are marked as shared in the model. We have other
applications that use the same EOModel.
Can't think of anything else at this time sorry.
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]
