This content has been marked as final. Show 4 replies
Hi Jeff, good to hear from you again.
When exposed as a ws, the whole xquery is executed before the call returns. There is no benefit of using async in hope of leaving something running beyond the life of the query.
For xqse exposed as a ws, the net result is the same, but for a slightly different reason. Although the result of an xqse could be possibly computed without waiting for the sp to complete, all the threads need to complete (or be killed) before the query can return.
I suppose that if there was a timeout, followed by an attempt to kill the thread that does not succeed in killing the thread. That could leave the thread running the stored procedure after the call returned (but there would be an exception for the timeout unless it was caught). Unless specified otherwise, I think the timeout for a call is 30 seconds.
Without exposing as a ws and using the java api with hasNext()/next(), the initial call only begins execution of a query, results are not computed (i.e. underlying calls are not made) until the results are "pulled" back to the client. And there is nothing that forces the client to read all the results or disconnect - so the client could simply abandon the call and leaving the executing query in limbo - complete with any resources (db connections) it is holding. At some point the session ejb for the query will be "idled" (serialized) and all the db connections should be eventually released.
I'm not sure what could be going on with your connection pool. Unless exceptions are being caught with fail-over, it's usually clear when things go bad.
Thanks for the quick reply, Mike.
I think we will remove that async call, since it doesn't seem to be doing what the programmer intended anyway. We have been experimenting with a few unrelated changes we think might have resolved the issue (particularly the caching of ken generation SEQUENCEs in the database).
Regarding that patch, I am not familiar with it...how can I see release notes for it?