> -----------------------------------------------------------
> comment: Ниже в транзакции (1) данные непосредственно не изменялись ни разу.
> :-)
>
> SM>Пример однопоточной параллельности:
> SM>старт первой транзакции (1).
> SM>старт вотрой транзакции (2).
> SM>в (1) фетч данных
> SM>в (2) адейт записи, входящей в отфетченный набор из (1)
> SM>commit (2)
> SM>рефетч уже запрепаренного запроса в (1)
> SM>commit/rolback (1) (не имеет значения, модификации не проводились).
> SM>Итого: в рамках одного подключения последовательно-параллельным способом
> SM>получены данные, живущие в сервере.
>
еще более клинический случай :-) Я там привел пример по удалению
данных во второй транзакции. Ну удобнее так работать. Тем более в
читающей надо просто прочитать записи, сгруппировать их а потом
распечатать. Если печать не пошла то надо откатить. Весь замут в том
что из зафетченного запроса могут быть удалены только определенные
записи, а печать ведеться по группам и в разные места. В любом месте
может произойти сбойи его надо откатить, при всем том что работа
остальных принтеров не должна прекращаться.
Мне предлагают запрос переоткрывать практически заново, хотя он
единовременно может выполниться только единственный раз и на одной
машине (если и на нескольких то удаляемые записи пересекаться не будут
однозначно. Да даже если бы и пересекались? кто запретить может
удаление записи если она уже удалена и в чем тут ошибка я так и не
понял если честно).
Если решать другими способами в одной транзакции то мне надо держать
обновляемый список в памяти, и после того как весь отфеченный запрос
отработал удалить их. Мне не кажется что это верный вариант. Тем
более сервер предоставляет дополнительные возможности которые очень
удобно ложаться на данную задачу. Клиника похоже в том что человек не
понимает как можно сделать читающую транзакцию, а обновление сделать в
другой. Чушь какая-то.
> IB: Транзакция обладает ACID-ностью.
> IB: Буковка I - изолированность. На практике это означает, что транзакция (2)
> не
> IB: может увидеть результат работы транзакции (1), до тех пор, пока (1) не
> зафиксировалась.
> IB: Если позволить делать такие фокусы, то это приведет к эффекту
> IB: Cascading Aborts - если ранзакция (2) зафиксируется, а транзакция (1) по
> каким-то причинам
> IB: не сможет, то и (2) надо тоже откатывать. Более того, надо откатывать все
> транзакции,
> IB: которые к этому времени успели попользоваться изменениями всесенными (2)
> - и далее по цепочке.
> IB: Если этого не делать, то окажется что транзакция (2) зафиксировала данные,
> IB: которые никогда не существовали.
Мне кажется или это блокировочное мышление проскальзывает у IB?
Андрей Кручинин
