Как организовать откат транзакции?

← →
YK © (2005-02-01 07:05) [0]

Уважаемые Мастера!
Подскажите пожалуйста, как
организовать откат транзакции для InterBase.
Нужно ли создавать транзакцию на сервере?
через Transaction.Rollback не работает:(

← →
Alexandr © (2005-02-01 07:08) [1]

чтобы сработал Transaction.Rollback
надо сначала писать Transaction.StartTransactionю
Некоторые кривые компоненты доступа позволяют не иметь явной транзакции, а создают ее сами, а вот как найти такую транзакию, надо смотреть у компонентов.

Правильные компоненты позволяют работать с несколькими транзакциями одновременно, и явно ими управляя.

Но в любом случае транзакции есть.

← →
YK © (2005-02-01 08:09) [2]

Я пишу Transaction.StartTransaction...
Может это из-за того что я делаю Transaction.commit?
После этого можно откатить транзакцию?

← →
Александр Иванов © (2005-02-01 08:14) [3]

Коммит фиксирует транзакцию и речь после этого можент идти только об откате базы, не знаю как это реализовано в ИБ.

← →
YK © (2005-02-01 08:17) [4]

Ясно,
значит в приложении следует
накапливать транзакции,
а затем всё commit?

← →
HSolo © (2005-02-01 09:01) [5]

>значит в приложении следует
накапливать транзакции,
а затем всё commit?

Зачем же так резко :) Как минимум, при такой работе все изменения, сделанные пользователем, никто другой не увидит аж до самого "все коммит" (ибо dirty read в IB нету), плюс будет у Вас море deadlock-ов... в общем, http://ibase.ru/devinfo/ibtrans.htm

← →
HSolo © (2005-02-01 09:09) [6]

Общее правило таково: "обновляющая" транзакция должна быть как можно короче. Т.е. чаще всего работают так: для чтения - одна транзакция read_commited; если надо что-то обновить - стартуем другую транзакцию, в ней обновляем и сразу ее commit, после чего перечитываем то, что надо перечитать, в 1-й транзакции.

← →
Sergey_Masloff (2005-02-01 09:38) [7]

HSolo © (01.02.05 09:09) [6]
Это совершенно не общее правило. Более того, слепое следование этому правилу может создавать проблемы. Хотя действительно во многих случаях такая схема работает отлично.

← →
HSolo © (2005-02-01 09:46) [8]

Sergey_Masloff (01.02.05 09:38) [7]

Да, каюсь, "общее правило" - термин неудачный.

← →
Johnmen © (2005-02-01 09:53) [9]

>Sergey_Masloff (01.02.05 09:38) [7]
>Это совершенно не общее правило.

Основания ?

>Более того, слепое следование этому правилу может создавать проблемы.

Какие ?

← →
Sergey_Masloff (2005-02-01 10:20) [10]

Johnmen © (01.02.05 09:53) [9]
>Основания ?
Усложнение кода без действительной на то необходимости. Чреватое ошибками коих я наблюдал немало ;-)

>Какие ?
Привычка не думая применять одну и ту же методологию. Очень большая проблема. А потом в пакетных операциях начинают каждую вставку коммитить. Не видал такого? ;-) А что-транзакция должна быть максимально короткой!

← →
Johnmen © (2005-02-01 10:26) [11]

Sergey_Masloff (01.02.05 10:20) [10]

Не, ну не надо углубляться в частные случаи. А то можно привести пример, где вообще не нужны пишущие...

← →
Sergey_Masloff (2005-02-01 10:29) [12]

Johnmen © (01.02.05 10:26) [11]
>А то можно привести пример, где вообще не нужны пишущие...
и читающие ;-)

← →
msguns © (2005-02-01 10:50) [13]

>Sergey_Masloff (01.02.05 10:20) [10]
А что-транзакция должна быть максимально короткой!

Не обязательно. Пример - откат прихода в складских системах с учетом по поставкам. При откате всего лишь одного прихода выполняется куча операций:
1. Все документы с позициями этого прихода откатываются
2. При откате каждого документа кол-ва товара его фактуры "возвращается" (для прихода - снимается) на склад
3. Делаются соотв.отметки в таблицах заказов и заявок
4. Делается пересчет текущих "живых" балансов.
5. В заголовках откаченных документов делаются правки.

И все это ДОЛЖНО ВЫПОЛНИТЬСЯ В РАМКАХ ОДНОЙ ПИШУЩЕЙ ТРАНЗАКЦИИ !

Это всего лишь один пример из огромного множества. Практически любая мало-мальски сложный проект содержит массу подобных "мулек".
Поэтому я бы разделил методику юзания транзакций на 2 большие категории:
- Для визуализации обмена данными между БД и клиентом
- Для реализации сложных многоступенчатых алгоритмов бизнес-логики.

← →
Sergey13 © (2005-02-01 10:55) [14]

Вклинюсь в спор с офтопиком.
Все таки говоря об "общих правилах" следует помнить, что это "общие правила" для ИБ.

← →
Sergey_Masloff (2005-02-01 10:56) [15]

msguns © (01.02.05 10:50) [13]
Ты меня неправильно прочел ;-) Посмотри еще раз - что я писал про короткие транзакции а не что ты прочел ;-)

← →
Sergey_Masloff (2005-02-01 10:58) [16]

Sergey13 © (01.02.05 10:55) [14]
>Вклинюсь в спор с офтопиком.
>Все таки говоря об "общих правилах" следует помнить, что >это "общие правила" для ИБ.
Да и для IB не общие.

← →
Sergey13 © (2005-02-01 11:01) [17]

2 [16] Sergey_Masloff (01.02.05 10:58)
Поэтому у меня и в кавычках. 8-)

← →
Johnmen © (2005-02-01 11:05) [18]

Общие правила для общих случаев...

← →
YK © (2005-02-01 12:50) [19]

Хороший пример со складской системой.
Но как это организовано?
Кстати насчет того чтобы commit после каждой записи...
Это плохо тем, что откатить нельзя?

Так чем лучше commit не после каждой записи?
Или нужно ждать rollback?
8-(

← →
Sergey13 © (2005-02-01 13:00) [20]

ИМХО, у тебя все таки отсутствует понимания самого термина - транзакция.
Транзакция это набор действий с БД обеспечивающий целостность и непротиворечивость данных. Это может быть и смена даты в гриде и перерасчет остатков по всем складам транснациональной корпорации. Без разницы, главное, что бы после завершения ее данные были целостными и непротиворечивыми.

В "commit после каждой зап" транзакция выступает как инструмент оптимизации, и в общем мало соотносится с собственно понятием транзакции. Может это и плохо звучит.

← →
Johnmen © (2005-02-01 13:11) [21]

ADD
ИМХО, у тебя все таки отсутствует желание почитать по приведенной ссылке и вникнуть, и => понимание самого термина - транзакция.

← →
yk © (2005-02-01 15:08) [22]

Насчет транзакции я почитал
почти весь ibase.ru
Просто я не могу понять как работает
компанент IBTransaction

Например я посылаю какой-нибудь
запрос из Query
затем делаю Commit
Изменения в базе подтвердились

Затем читаю из базы

Если я хочу отменить результату запроса, то следует делать rollback?

"я почитал" (c) Катюха

Прикольно :)

Уважаемые Мастера!
Я всё-таки разобралась с транзакциями.
Как всегда у меня бывает,
ваш ответы были абсолютно верными, и я действительно не понимала суть транзакций (хотя может быть и теперь не очень поняла).
Но как говориться, пока сам не сделаешь - ничего не поймешь.

Короче так:
транзакции это не такой классный способ применения/отмены типа (Undo/Redo) это такие штучки для поддержания целостности базы данных и короче от глюков (простите за дурацкую формулировку)...

Для их использования делают так:

if(IBTransaction.Active=false)then
begin IBTransaction.StartTransaction;end ;
try
IBQuery.Open;
IBTransaction1.Commit;
{если всё хорошо , то изменения в базе данных сохранились}
except
IBTransaction1.Rollback;
{если глюк - то базу данных не мучаем}
end;

Большое спасибо Всем!

[23] Johnmen © (01.02.05 15:21)
Ну что-ты так сразу. Может это он операцию по смене пола недавно сделал, не привык еще, ему теперь понимание и сочуйствие надо, а ты смеешся. Ай-яй-яй. :))

[24] YK © (04.02.05 05:49)
> транзакции это не такой классный способ применения/отмены
> типа (Undo/Redo) это такие штучки для поддержания целостности
> базы данных и короче от глюков (простите за дурацкую формулировку)...

Транзакции это не штучки. Транзакция это неделимый, для сервера, набор операций, либо они все выполняются (commit) либо ничего не выполняется (rollback).

> if(IBTransaction.Active=false)then
begin IBTransaction.StartTransaction;end ;

Убираем корявость и делаем код читабельным:

with IBTransaction do
if not InTransaction then StartTransaction;

>try
// IBQuery.Open;
<Что-то меняем в БД (ХП или пишущий запрос)>
IBTransaction1.Commit;
except
IBTransaction1.Rollback;
end;

Транзакциям, в которых данные только читаются,коммит давать не обязательно. По завершению проги они "закрываются" автоматически.
После коммита/роллбака пишущих транзакций переоткрывать НД, связанные с таблицами БД, измененными этими транзакциями, но работающие в контексте других транзакций.
Если "читающая" транзакция типа снапшота ("копия" БД на момент старта транзакции), то после коммита пишущих транзакций надо перестартовать ее, а все запросы переоткрыть

При изучении механизма транзакций особое внимание уделяем параметрам транзакции и понимаю конкурентости и изолированности транзакций.

Желаю успеха !

[27] msguns © (04.02.05 10:27)
> При изучении механизма транзакций особое внимание уделяем
> параметрам транзакции и понимаю конкурентости и изолированности
> транзакций.

Угу. Вообще, для IB и клонов желательно иметь несколько транзакций, по-крайней мере две - одну только для чтения, в которой открывать запросы, результаты которых вываливаются во всякие гриды, а вторая для записи, которая стартует и завершается в одной процедуре записи, дабы эта вторая была очень короткой.

2[28] Danilka © (04.02.05 10:32)
А я применяю отдельную пишущую транзакцию в основном только тогда, когда мне нужны действительно согласованные действия, типа одновременное удаление/вставка/изменение разных таблиц. Меняя в гриде можно закомитить и текущую, главное не забывать про это. На перечитывании опять же экономлю. Может сказывается, что в основном я с Оракулом работаю - привычка.

[29] Sergey13 © (04.02.05 10:45)
Дык, только для чтения транзакции стоят дешевле, думаю будет заметно на большой нагрузке сервера, когда долгие транзакции только для чтения, а отдельные короткие на запись.
Хотя, если честно, сам уже давно с IB не сталкивался, да и когда сталкивался, то негрузка небольшая. Сам на работе только с Ороклом дело имею, а IB, MSSQL это уже так, халтурка или для себя. :))

[29] Sergey13 © (04.02.05 10:45)
И вообще, мне нравятся последнее время клиентские курсоры - закачал что надо и закрыл транзакцию, поменял все что надо - открыл транзакцию, внес изменения, завершил ее. Главное не переборщить с забираемыми с серверами данными, много сразу не просить. Влияние АДО и МССкуля. :)) Но стандартными компонентами доступа для IB такой номер не пройдет.

Поправка к [27]
Фразу
После коммита/роллбака пишущих транзакций переоткрывать НД, связанные с таблицами БД, измененными этими транзакциями, но работающие в контексте других транзакций.
читать как
После коммита пишущих транзакций переоткрывать НД, связанные с таблицами БД, измененными этими транзакциями, но работающие в контексте других транзакций

Если пишущая откачена, то перечитка отображаемых курсоров не нужна (за исключением некоторых особых случаев, но это уже дебри)

Как организовать откат транзакции? Найти похожие ветки