Re: WOLongResponse and EO processing
Re: WOLongResponse and EO processing
- Subject: Re: WOLongResponse and EO processing
- From: Allen Cronce <email@hidden>
- Date: Wed, 11 Aug 2004 09:04:19 -0700
Hi all,
I'd like to resurrect this topic. We recently tracked down a rare but
nasty set of deadlocks that happened because we were inadvertently
accessing EO objects using the default EOObjectStoreCoordinator in a
WOTimer thread. Now we are reevaluating any EO access in threads across
the application implementation, including in the performAction method of
WOLongResponse pages.
I tend to agree with Richard below that the only safe way to access EO
objects in a performAction method thread is to create an independent
access layer stack by instancing a new EOObjectStoreCoordinator. But I
think the problem is far worse than he stated in his example.
We've found that when multiple threads access EO objects in the same
EOObjectStoreCoordinator, they in fact sharing a single connection to
the database, which can result in the inadvertent intermix of SQL from
the threads of a given application instance in a single database
transaction. So rather than orderly transactions of SQL selects and
commits, you can get multiple selects from different threads in a given
transaction. Depending on how your database is configured, this can
result in an increased possibility of contention for locked tables,
which can result in all sorts of difficult to debug database exceptions.
So my current thinking is that we need to rework our performAction
implementations to use new, non-default EOObjectStoreCoordinators. But
before we go on a rewrite binge, I thought I'd ask if anyone out there
has a counter opinion.
Thanks in advance for any thoughts.
Best regards,
Allen Cronce
Richard Bruch wrote:
Hello Sam,
i think generally one should. The component request handling is usually not
concurrent which means the requests are served one after another. Now imagine
that the WOLongResponsePage is just executing a lengthy fetch using the
database context registered with the default EOObjectStoreCoordinator. In this
state the database context is locked for the time of the fetch.
In the meantime an ordinary request A for an ordinary component page arrives
which asks the session().defaultEditingContext to fetch a couple of objects
with a fetch spec. This editing context also uses the default store
coordinator which means it also uses the same database context and therefore
would lock on an internal call to that database context. Now a meta-refresh
request B arrives from the browser displaying the long response page. B will
wait till A is completed. But A is completed as soon as the long fetch is
finished which can be long time from there. After a short period your browser
would display a message "Server not responding". So even if this is not a real
deadlock it would look just like that. A different database context would
resolve the issue.
-----------------------------------------------------------------------------
---
You shouldn't need to create a new EOObjectStoreCoordinator ( I think)
, simply creating a new EOEditingContext should suffice. In the long
response component method which accepts the qualifier or array of
records to display I'd put something like this:
EOEditingContext ec = new EOEditingContext();
EODatabaseDataSource ds = new EODatabaseDataSource(ec, "MyEntityName");
displayGroup.setDataSource(ds);
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.