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 11:35:16 -0700
Hi Richard,
What we did to diagnose this problem was look at the FrontBase SQL
transaction log, which includes all the SQL to the database and the
results. When compared to our application log information, it certainly
looks like we are seeing an unintentional merge of SQL from multiple
threads in a single transaction.
Here's an example of what we are seeing (with the details removed):
Select from thread A (from a request/response loop)
Select from thread B (from the WOTimer thread)
Select from thread B
Insert from thread A
Commit
I won't go into details as to the tables and errors because I don't think
that level of detail is useful for this discussion. Needless to say when
the above happens, all hell breaks loose.
I guess it's possible that we've misinterpreted this information, but I
don't think so. It really looks like when two threads (one from a
request/response loop and the other from a timer) are sharing a
connection to the database, there is a non-zero probability that they
will also share a transaction.
Best regards,
Allen Cronce
Richard Bruch wrote:
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.
_______________________________________________
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.