CommitRetaining и mon$ таблицы

Привет вем.

Вот в чем вопрос:

Есть приложение, которое после коннекта к FB2.5 создает записи в некой своей таблице LOGIN_LOG и делает CommitRetaining(параметры транзакции: write nowait rec_version read_committed). В приложении две транзакции. Одна - для обслуживания чтений, другая - записи. В момент записи читающая транзакция открыта.
Потом стартует другая копия приложения и при старте делает то же самое. Итого - две новых записи в этой таблице.

Потом первая копия в какой-то момент читает эту таблицу, и замечательно видит две записи(параметры транзакции: read nowait rec_version read_committed). Я счастлив

Но, есть еще таблица mon$attachments. И вот, когда первая копия приложения начинает читаь её(транзакция та же, что и раньше), то она, блин, видит там только ОДНУ запись(о себе, любимой), а второй записи, созданной при коннкте второй копии, она не видит.


Вопросы:
1. Почему?
2. Кал лечить?(коммит читающей транзакции не предлагать. Это я сам умею).

Заранее спасибо.

PriBoy
и делает CommitRetaining

обострение, чтоль. Зачем CommitRetaining?

PriBoy
Но, есть еще таблица mon$attachments. И вот, когда первая копия приложения начинает читаь её

за обращение к mon$ в пользовательских приложениях стоит назначить вырывание ногтей разработчику.

PriBoy
Вопросы: 1. Почему? 2. Кал лечить?(коммит читающей транзакции не предлагать. Это я сам умею).

1. Потому что таблицы мониторинга - всегда snapshot. Обновляются один раз за транзакцию.
2. Как уже сказал kdv - не надо их использовать таким способом.

Posted via ActualForum NNTP Server 1.5

PriBoy
Но, есть еще таблица mon$attachments. И вот, когда первая копия приложения начинает читаь её(транзакция та же, что и раньше), то она, блин, видит там только ОДНУ запись(о себе, любимой), а второй записи, созданной при коннкте второй копии, она не видит.

Это потому, что все операции с mon$-таблицами работают так, как если бы транзакция стартовала в режиме snapshot. В доке к 2.1 об этом прямо так и написано:

+

The Concept The key term of the monitoring feature is an activity snapshot. <...> A snapshot is created the first time any of the monitoring tables is being selected from in the given transaction and it is preserved until the transaction ends, in order that multiple-table queries (e.g., master-detail ones) will always return a consistent view of the data. In other words, the monitoring tables always behave like a snapshot table stability (“consistency”) transaction, even if the host transaction has been started with a lower isolation level. To refresh the snapshot, the current transaction should be finished and the monitoring tables should be queried in a new transaction context.

А вот в доке к 2.5 этого важного замечания почему-то не видно. Оттого многие (и мну в том числе) неоднократно лбами налетали/налетают/будут_налетать на сиё.