Subject | Re: [firebird-support] Cancel long running queries |
---|---|
Author | Helen Borrie |
Post date | 2009-06-15T22:50:07Z |
At 01:52 AM 16/06/2009, you wrote:
As Douglas said, in future versions it will be possible to delete an attachment from MON$, i.e., kill a superserver/superclassic thread or a classic process. That will have (more or less) the equivalent effect to shutting down the entailed attachment thread[s] for SS or SC (not possible in 2.1 except by shutting down the entire server or waiting n hours for the network to signal dead connection) or killing the process for CS (which has always been possible anyway).
./heLen
>HelloIt will stop a query that is extant (still fetching, executing or prepared).
>
>Using Firebird 2.1.2 does the following command only stop queries that are still being processed:
>
>'delete from mon$statements where MON$STATEMENT_ID = 123'
>For example if the SQL statement we wish to stop was a select which had already returned the results but had not yet been committed. Can you use the 'delete from mon$statements' to effectively cancel the transaction? So that the OAT would be released.No. Any transaction, other than one that is read-only Read Committed, remains active until it is either committed or rolled back, even if it has been stripped of all statement requests it has executed. (A read-only read committed transaction is effectively "pre-committed", in the sense that it never impacts the OAT at any point in its life). A statement exists within a transaction context; a transaction, in turn, exists within an attachment context. If you've lost the ability to commit or roll back the transaction then terminating the attachment is the only way to end the marooned transactions.
As Douglas said, in future versions it will be possible to delete an attachment from MON$, i.e., kill a superserver/superclassic thread or a classic process. That will have (more or less) the equivalent effect to shutting down the entailed attachment thread[s] for SS or SC (not possible in 2.1 except by shutting down the entire server or waiting n hours for the network to signal dead connection) or killing the process for CS (which has always been possible anyway).
./heLen