EOAdaptorChannel.cancelFetch() problem

[patrickx at onestep.co.uk (Patrick Middleton)]

WO5.2.1 on MacOSX 10.2.6 + Sybase (on the same box)

We're developing a MIS app.  Some queries take a long time to complete, 
and may return huge numbers of rows.  We have WOLongResponsePage, and a 
"how to interrupt a long running fetch" technique remarkably similar to 
the one mmalc described some years ago; set an artificially low 
fetchLimit in the EOFetchSpecification, and have set things up so that 
the EOEditingContext's messageHandler is polled to see if we should 
continue fetching.  However, after cancelling a fetch, sometimes the 
next attempt to search gets a "no instance available" response, and 
while thinking about this, the woapp fails with an OutOfMemory exception.


So I enabled SQL logging, and implemented some 
EOAdaptor[Channel|Context] API to log certain events as well.


This fetch returned the first 10000 of about 50000 rows for the query.  
Note the 264-second delay between "row(s) processed" and "Commit 
Internal Transaction"


Thu Jul 10 16:45:18 BST 2003 -- 
MyLongResponse.adaptorChannelShouldSelectAttributes() returning true
[2003-07-10 16:45:18 BST] <Thread-4>  === Begin Internal Transaction
[2003-07-10 16:45:18 BST] <Thread-4>  evaluateExpression: ....
Thu Jul 10 16:45:18 BST 2003 -- 
MyLongResponse.adaptorChannelShouldSelectAttributes(...)
[2003-07-10 16:46:19 BST] <Thread-4> fetch canceled
[2003-07-10 16:46:19 BST] <Thread-4> 10000 row(s) processed
[2003-07-10 16:50:45 BST] <Thread-4>  === Commit Internal Transaction



This fetch returned all rows for the query.  Note the 0-second delay 
between "row(s) processed" and "Commit Internal Transaction"

Thu Jul 10 16:57:47 BST 2003 -- 
MyLongResponse.adaptorChannelShouldSelectAttributes() returning true
[2003-07-10 16:57:47 BST] <Thread-5>  === Begin Internal Transaction
[2003-07-10 16:57:47 BST] <Thread-5>  evaluateExpression: ....
Thu Jul 10 16:57:48 BST 2003 -- 
MyLongResponse.adaptorChannelDidSelectAttributes(...)
[2003-07-10 16:58:19 BST] <Thread-5> 2577 row(s) processed
[2003-07-10 16:58:19 BST] <Thread-5>  === Commit Internal Transaction



If I didn't know better, I'd think that .cancelFetch() isn't invoking 
vendor-specific-API to stop row data being transferred, it's continuing 
to fetch rows but not holding on to the results; so the database 
channel/adaptor channel remains busy, contention for the database 
connection causes application response timeouts in other pages, and 
memory is being consumed faster than the gc mechanism can recycle it.


Anybody got better knowledge of this problem than me?  Does anybody know 
if this is EOF, JDBC, or Sybase's JDBC driver at fault?

Patrick

--
Patrick Middleton
OneStep Solutions plc
351 London Road             Phone: +44 (0)1702 426400
Hadleigh                    Fax:   +44 (0)1702 556855
Essex. SS7 2BT              Email: patrick@xxxxxxxxxxxxx
England                            (MIME welcome)