On 25.01.2008, at 11:10, Chuck Hill wrote:

I don't think that is exactly correct. EOF is only blocked during a fetch or a save. Unless the thread is doing a lot of fetches or making long saves (lots of EOs), EOF locking should not be a problem.

As long as you're not locking stuff somewhere where it's a bad idea. Sure, you can work concurrently on EOF objects but the connection to the database stays as the main bottleneck. And yes, you're right - I wasn't clear on that. It not necessarily blocking.

There is a common and similar problem. If the thread uses and locks an EC that is also locked by the session, the user's session will be blocked until the thread exits. Is that what you were thinking of?

Not really. There are some really nasty problems you can run into when you work on eos coming from a different thread - I ran in nearly all of them over the time.

Locking definitely is an issue, some people pass objects into the thread that are in the sessions default editing context - which is an even uglier thing. Not too long ago I had a problem where something was retrieving an object from the session's default editing context, ERXEC autolocking would lock it (outside RR loop), than the session comes back to life and is blocked because it can't lock the default editing context ...

But where I was heading is that you normally do "long running and / or database heavy" tasks in a separate thread and in a WO app that more often than not means you're handling a lot of database traffic which might block (or slow down to a crawl) the rest of your app until the thread is done if you stay on the same database connection.

cug

--
Real-World WebObjects class at the Big Nerd Ranch
March 2008, Frankfurt, Germany
http://www.bignerdranch.com/classes/webobjects.shtml

_______________________________________________
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]

Reply via email to