Re: WOLongResponse and EO processing
Re: WOLongResponse and EO processing
- Subject: Re: WOLongResponse and EO processing
- From: "Richard Bruch" <email@hidden>
- Date: Wed, 11 Aug 2004 18:39:52 +0200
Hi Allen,
i don't think, inadvertant intermix of SQL from different threads can take
place. As the WO documentation states, access to a database context is always
protected by an exclusive lock which only one thread at a time can hold.
The situation i described below can however happen very quickly. You can enable
concurrent request handling but this doesn't solve the problem completely since
a single user can open a session, duplicate a page within his browser, then
start a lenthy action in the first window using WOLongResponsePage and then try
to do something other in between in the second window.
Jonathan Rochkind has confirmed that the request handling within a given session
is serialized in the check out method so regardless whether concurrent request
handling is enabled or not, a given user could easily run into the kind of
problem i described even if that can protect different users from each other.
That's true that the same EOObjectStoreCoordinator uses the same physical
database connection(by using the same database context) to a database for all
editing contexts based on it.But the database context access is synchronized.
And even if you can use it from different threads this should not cause problems
as long as you use different editing contexts since any of them has its own set
of objects and should have its own transaction scope - at least with Oracle, any
saveChanges request is completed with a commit to the backend database so it is
ensured that subsequent saveChange requests from different editing contexts are
executed in different transactions from the Oracle's point of view.
What i never did however were to use the same editing context concurrently. This
could be really dangerous.
Regards,
Richard
----- Original Message -----
From: "Allen Cronce" <email@hidden>
To: "Richard Bruch" <email@hidden>
Cc: <email@hidden>; <email@hidden>
Sent: Wednesday, August 11, 2004 6:04 PM
Subject: Re: WOLongResponse and EO processing
> 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.