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.
