Re: Enumerating EOs in a new thread
Re: Enumerating EOs in a new thread
- Subject: Re: Enumerating EOs in a new thread
- From: Guido Neitzer <email@hidden>
- Date: Fri, 25 Jan 2008 13:44:34 -0700
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden