Subject | Re: [firebird-support] Explanation of entry in Monitoring Tables |
---|---|
Author | Helen Borrie |
Post date | 2008-11-03T23:46:09Z |
At 10:08 AM 4/11/2008, you wrote:
If it's a parameterised statement that the application needs to run repeatedly with a variety of parameter assignments in the WHERE clause, then keeping it prepared is good -- recommended practice in general.
If the app is constructing static SQL each time it wants that set or operation, then keeping such a statement prepared after the commit or rollback is a pointless leakage of resources, although it's not interfering with transaction accounting. Smart native interfaces like IBO or Jaybird will usually clean up after such statements under most conditions; otherwise you will want to take care of the unprepare explicitly, especially if attachments are long-lasting or beyond your control.
./heLen
>I am seeing a record in the monitoring tables which looks suspiciousIt's a prepared statement that no transaction is currently executing. It is just waiting until that attachment decides to execute it again.
>and would like some explanation, if possible. The query I am issuing
>is:
>
>Select *
>from Mon$Statements ms
>join mon$attachments ma on (ma.mon$attachment_id = ms.mon$Attachment_ID)
>join mon$transactions mt on (mt.mon$attachment_id =
>ms.mon$attachment_ID)
>
>I am seeing a set of records with the same mon$attachment_id with an
>SQL statement populated in Mon$SQL_Text, but the mon$transaction_id is
>null and the mon$state is 0.
>
>Shouln't there be an associated transaction with this record or is this
>entry pointing to some other issue?
If it's a parameterised statement that the application needs to run repeatedly with a variety of parameter assignments in the WHERE clause, then keeping it prepared is good -- recommended practice in general.
If the app is constructing static SQL each time it wants that set or operation, then keeping such a statement prepared after the commit or rollback is a pointless leakage of resources, although it's not interfering with transaction accounting. Smart native interfaces like IBO or Jaybird will usually clean up after such statements under most conditions; otherwise you will want to take care of the unprepare explicitly, especially if attachments are long-lasting or beyond your control.
./heLen