Помогите найти доводы для начальства

← →
Александр Иванов © (2006-06-23 09:26) [0]

Правильно ли держать открытую транзакцию, при редактировании данных пользователем? Я считаю, что неправильно, начальство хочет заставить это сделать.

← →
ANB © (2006-06-23 09:29) [1]

Скажи начальнику, что он дурак.

Если не хочешь говорит лично, попроси его завести топик на SQL.RU. Ему там об этом много народу скажет.

← →
Александр Иванов © (2006-06-23 09:29) [2]

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

← →
Александр Иванов © (2006-06-23 09:31) [3]

ANB © (23.06.06 09:29) [1]

Это не совсем довод :)

← →
Ega23 © (2006-06-23 09:33) [4]

Смотря какой Isolation Level. ИМХО.

← →
Тульский © (2006-06-23 09:35) [5]

Я - начальник, ты - дурак (с)

← →
ANB © (2006-06-23 09:37) [6]

> Александр Иванов © (23.06.06 09:31) [3]

1. Доводы там укажут.
2. Кеширование надо делать на клиенте. Делать это с помощью транзакций - нарываться на проблемы блокировок.
Имхо :
Транзакция, согласно определения, это некая совокупность действий с БД, которая должна либо выполнится вся, либо не выполнятся совсем. При этом рекомендуется транзакцию выполнять как можно быстрее, т.к. частенько при этом выставляются блокировки.
Сама идея кеширования меня никогда не привлекала, т.к. приходилось на своих программах рабоать. Очень неудобно, когда полчаса или больше забиваешь какой то список, а потом из за какой то причине, на последней строке все отваливается и работа ушла впустую. Я бы сделал буферную таблицу, куда все складывал, а при нажатии кнопки "сохранить" переписывал в боевые таблицы.

← →
Александр Иванов © (2006-06-23 09:37) [7]

Ega23 © (23.06.06 09:33) [4]

Что-то не нашел я выбора уровня в ODAC, работаю с Ораклом

← →
Ega23 © (2006-06-23 09:39) [8]

> Что-то не нашел я выбора уровня в ODAC, работаю с Ораклом

Тады сорри, с Ораклом не знаком...

← →
ANB © (2006-06-23 09:41) [9]

> Александр Иванов © (23.06.06 09:37) [7]

Для оракла как раз категорически не рекомендуется держать транзакцию на время редактирования данных пользователем (который может уйти курить или вообще домой). Однозначно вылезут грабли при сетевой работе.

← →
ANB © (2006-06-23 09:43) [10]

Уровень изоляции у оракла как то менять можно (хотя я не уверен), но :
1) Никто этого не делает
2) по причине 1) обычно мало кто знает как.
Вроде как я видел что то в настройках инстанса. Но из клиента его точно не поменяешь.

← →
Александр Иванов © (2006-06-23 09:45) [11]

ANB © (23.06.06 09:43) [10]

В дот Нете с уровнями в Оракле работал, здесь не нашел.

← →
ANB © (2006-06-23 09:45) [12]

> Александр Иванов © (23.06.06 09:37) [7]

Таки задай вопрос на SQL.ru. Ща придет мой начальник, он там постоянно пасется (модератор softwarer), он твоего начальника аргументированно размажет по стенке. Только задай его с уверенностью, что так делать и надо (от лица своего начальника). Тогда точно обратят внимание и размажут.

← →
ANB © (2006-06-23 09:47) [13]

> В дот Нете с уровнями в Оракле работал

Я, честно говоря, даже не знаю, как будет работать оракл при изменении уровня изоляции. Скорее всего, он игнорировал твои настройки в дот.нете.

← →
Курдль © (2006-06-23 09:48) [14]

> Александр Иванов © (23.06.06 09:37) [7]
> Что-то не нашел я выбора уровня в ODAC, работаю с Ораклом

И не ищи! Работать с ораклом и при этом использовать грязное чтение, - это волюнтаризЬм!
Оракл не блокирует доступ к таблицам, у которых открыты транзакции (на от он и оракл, а не МС СКЛ). Однако, начинает жрать ресурсы.
Я не представляю Вашей конечной цели, но в моих проектах всегда были формы, на которых предполагалось редактирование многих строк и даже многих взаимосвязанных таблиц одновременно. Все это нормально разруливают датасэты с кэшированием. Лучше всего - датасэты от ADO.NET.

← →
Александр Иванов © (2006-06-23 09:52) [15]

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

← →
Курдль © (2006-06-23 09:54) [16]

> Александр Иванов © (23.06.06 09:52) [15]

Все равно не ясно :(
Деревянная структура?
Что значит "все связанные"? Друг с другом?

← →
Danilka © (2006-06-23 09:55) [17]

[11] Александр Иванов © (23.06.06 09:45)
> В дот Нете с уровнями в Оракле работал, здесь не нашел.

Хм.. наоборот, в дотнете все заточено на работу с клиентскими курсорами и внесением всех изменеий одной процедурой, то-есть транзакции минимально короткие, я даже не представляю, как там с серверными курсорами работать-то.

[15] Александр Иванов © (23.06.06 09:52)
А по подробней можно? Шото я не понял ничего, а особенно, зачам здесь длинные транзакции.

← →
Александр Иванов © (2006-06-23 09:59) [18]

Danilka © (23.06.06 09:55) [17]

Там просто при создании транзакции один из параметров - уровень изоляции.

← →
Danilka © (2006-06-23 10:06) [19]

[18] Александр Иванов © (23.06.06 09:59)
Понятно, просто я смысла не вижу, если все транзакции - короткие.

← →
Александр Иванов © (2006-06-23 10:08) [20]

Danilka © (23.06.06 09:55) [17]

Ну список там обычный, одно из полей - ссылка на предыдущую запись

← →
Danilka © (2006-06-23 10:15) [21]

[20] Александр Иванов © (23.06.06 10:08)
Извини, все равно непонятно нифига :))

На клиенте есть список, так?
Там-же на клиенте есть грид, так?
Выбираем какую-то запись из списка, она попадает в грид, а из списка исчезает?

← →
Александр Иванов © (2006-06-23 10:32) [22]

Danilka © (23.06.06 10:15) [21]
Таблица в базе, на клиенте грид с кешированием. В грид попадают записи из другой таблицы, которых нет в гриде, фильтрацию осуществляет хранимая процедура, следовательно ей надо сообщать о тех записях, которые уже добавлены. Из-за этого предлагают отказаться от кеширования, и держать открытую транзакцию, в момент начала редактирования.

← →
Sergey13 © (2006-06-23 10:40) [23]

> [22] Александр Иванов © (23.06.06 10:32)

С такими описаниями задачи не мудрено, что вы идете нестандартными путями.

← →
Danilka © (2006-06-23 10:46) [24]

[22] Александр Иванов © (23.06.06 10:32)

> Таблица в базе, на клиенте грид с кешированием

Понятно

> В грид попадают записи из другой таблицы, которых нет в
> гриде

как я понимаю, во время редактирования попадают?

> фильтрацию осуществляет хранимая процедура

фильтрация чего?

как вообще происходит редактирование? если не сИкретная информация, можно более подробно расписать, а то до сих пор нифига не понятно, например:
есть таблица А с полями А1, А2, А3.
Есть таблица Б с полями Б1, Б2, Б3.
тваблица А открывается в гриде.
таблица Б - список.
юзер выбирает запись из списка, в результате в гриде формируется новая запись. сейчас эта операция сделана с помощью ХП - информация о записи из Б попадает таблицу какую-то на сервере и грид с записями А переоткрывается...

← →
Курдль © (2006-06-23 10:58) [25]

> Александр Иванов © (23.06.06 10:32) [22]

Можете сработать гораздо продуктивнее, описав задачу на уровне предметной области, а не ваших корпоративных фантазий на тему использования замысловатых взаимосвязей записей и процедур. Проще говоря: что надо-то получить и из чего?

Вот это мне тоже непонятно:

> Ну список там обычный, одно из полей - ссылка на предыдущую
> запись

Что, "хвост в гриву"? Или все же "родитель - наследник"?

← →
Val © (2006-06-23 11:00) [26]

Между прочим, пока я не понимаю, из приведенного описания, чем в данном случае плох select for update. Вам пофиг, что другие юзеры будут менять у себя те же выбранные вами, например, в клиентский кеш записи, а потом вы выброской из кеша все их изменения похерите?

← →
Desdechado © (2006-06-23 11:12) [27]

Я читал-читал, но так и не понял, что именно автор хочет (или не хочет) сделать.
А по "держать открытую транзакцию, при редактировании данных пользователем" думаю, что если транзакция только читающая, то держи, сколько влезет.
Редактировать датасет на клиенте можно и так. Изменения потом в короткой транзакции(ях) можно скинуть на сервер. Обычно одни и те же данные 2 чела не редактируют (разные сферы ответственности). Но даже если так, то кто последний, тот и папа.

← →
Курдль © (2006-06-23 11:20) [28]

> А по "держать открытую транзакцию, при редактировании данных
> пользователем" думаю, что если транзакция только читающая,
> то держи, сколько влезет.

Проснитесь!!! Не бывает у оракла "читающих транзакций"! Это продукт воспаленной фантазии авторов IB!
Он имел в виду конкретно транзакцию "пишущую"!

← →
Reindeer Moss Eater © (2006-06-23 11:29) [29]

Правильный ответ надо искать в логике работы с данными конкретной предметной области. а не среди множества усвоеных с опытом правил и аксиом.

← →
Desdechado © (2006-06-23 11:36) [30]

> Не бывает у оракла "читающих транзакций"!
Я не настолько знаком с Ораклом, чтобы спорить. Прошу указать, где в документации это написано.
Логически же рассуждая, не верю, что SELECT блокирует записи от изменения. Данные получены, серверу должно быть уже все равно, что с ними будет делать клиент, особенно если он ничего делать не собирается.

> Он имел в виду конкретно транзакцию "пишущую"!
1. Не вижу, из каких объяснений автора это следует.
2. Если нет "читающих", значит абсолютно все "пишущие"?

← →
Александр Иванов © (2006-06-23 11:38) [31]

транзакция "пишущая". Структуру базы разрабатывал не я и менять мне не дадут, поэтому и задавал конкретный вопрос.

← →
MsGuns © (2006-06-23 11:52) [32]

Ох, и любят же здесь длиннючие дискуссии ни о чем ;))

← →
Курдль © (2006-06-23 11:54) [33]

> Desdechado © (23.06.06 11:36) [30]
> Я не настолько знаком с Ораклом, чтобы спорить. Прошу указать, где в документации это написано.

Не буду даже искать. Просто нет такого понятия в нормальных СУБД "читающая транзакция". Даже сам термин "транзакция" не предполагает простого созерцания.

> Александр Иванов © (23.06.06 11:38) [31]
> транзакция "пишущая". Структуру базы разрабатывал не я и
> менять мне не дадут, поэтому и задавал конкретный вопрос.

Однако, если хотите, чтобы Вас поняли, - вот мой совет - старайтесь в описаниях приближаться к универсальному языку проектирования БД.
Не надо нам про таблицы, ключи, индексы и их связи. Оперируйте сущностями, связями и правилами.

← →
evvcom © (2006-06-23 11:58) [34]

> [7] Александр Иванов © (23.06.06 09:37)

В ОДАКе я не искал, но в документации по Ораклу есть следующее:
ISOLATION_LEVEL
Syntax:
ISOLATION_LEVEL = {SERIALIZABLE | READ COMMITTED}
The ISOLATION_LEVEL parameter specifies how transactions containing database
modifications are handled. ISOLATION_LEVEL is a session parameter only, not an
initialization parameter.

Но не думаю, что тебе это надо. Я тоже ничего не понял из твоих объяснений, что ж ты хочешь?

← →
Val © (2006-06-23 12:00) [35]

>[34] evvcom © (23.06.06 11:58)
:) из описания никто ничего не понял вот и трепемся помалеху, пока автор описание пишет...

← →
evvcom © (2006-06-23 12:04) [36]

> [35] Val © (23.06.06 12:00)

:) ну это я понял. Недаром ветка в "потре...", ой! в "прочем". :-)

← →
Desdechado © (2006-06-23 12:05) [37]

Курдль © (23.06.06 11:54) [33]
> нет такого понятия в нормальных СУБД "читающая транзакция".
> Даже сам термин "транзакция" не предполагает простого созерцания.
Т.е. SELECT выполняется вне контекста транзакции?! А если он единственный запрос за все время работы с БД?

← →
Sergey13 © (2006-06-23 12:13) [38]

> [37] Desdechado © (23.06.06 12:05)
> Т.е. SELECT выполняется вне контекста транзакции?! А если
> он единственный запрос за все время работы с БД?

Ну и что?

← →
evvcom © (2006-06-23 12:18) [39]

> нет такого понятия в нормальных СУБД "читающая транзакция".

А вот что пишет Том Кайт:
SET TRANSACTION. Этот оператор позволяет устанавливать атрибуты транзак-
ции, такие как уровень изолированности и то, будет ли она использоваться толь-
ко для чтения данных или для чтения и записи. Этот оператор также позволяет
привязать транзакцию к определенному сегменту отката.

← →
Sergey13 © (2006-06-23 12:22) [40]

> [39] evvcom © (23.06.06 12:18)

Ну и что? Этот оператор устанавливает свойства транзакции, а не стартует ее. Вся сессия, по большому счету - "читающая транзакция", хотя мне лично тоже этот термин слух слегка режет 8-).

← →
Курдль © (2006-06-23 12:30) [41]

> Desdechado © (23.06.06 12:05) [37]
> Т.е. SELECT выполняется вне контекста транзакции?! А если
> он единственный запрос за все время работы с БД?

Кому какая разница, чего я там читаю? Для всех правила одинаковы.
Если я открыл в своей сессии транзакцию принудительно и что-то там прочитал, ничего в БД не изменив, - я получу абсолютно те же данные, что и просто по запросу. Другое дело, если я открыл транзакцию, чего-то в базе натворил, а потом читаю результаты. Вот тогда я действительно увижу уникальный срез данных, характерный только для моей сессии (с учетом моих не утвержденных commit-ом изменений).

> evvcom © (23.06.06 12:18) [39]

Согласен, что транзакция может быть настроена на определенный уровень изоляции. Но в случае с ораклом - надо иметь какую-то чрезвычайно нетривиальную задачу, чтобы этим воспользоваться.

← →
Desdechado © (2006-06-23 12:43) [42]

> я получу абсолютно те же данные, что и просто по запросу.
Я повторю вопрос: SELECT может выполняться вне контекста транзакции?!

← →
Sergey13 © (2006-06-23 12:49) [43]

> [42] Desdechado © (23.06.06 12:43)
> Я повторю вопрос: SELECT может выполняться вне контекста
> транзакции?!

Повторю ответ: вся сессия - одна большая транзакция, если нет коммитов/ролбеков. Если есть, то сессия - непересекающаяся последовательность транзакций.

← →
evvcom © (2006-06-23 12:55) [44]

> а не стартует ее

А я и не говорил, что транзакция стартуется. Я только хотел обратить внимание, что все-таки понятие "читающей транзакции" имеется. И еще, для чего же это все-таки? Приведу опять Тома Кайта:
Помимо четырех уровней изолированности транзакции, определенных в стандарте
SQL92, Oracle обеспечивает еще один уровень — транзакции только для чтения. Тран-
закция только для чтения эквивалентна при чтении уровню изолированности
REPEATABLE READ или SERIALIZABLE в SQL92. Такая транзакция видит только
изменения, зафиксированные на момент ее начала, но в этом режиме не разрешена
вставка, изменение и удаление данных (другие сеансы могут изменять данные, но тран-
закция только для чтения — нет). Используя этот режим, можно достичь уровней
REPEATABLE READ и SERIALIZABLE READ без чтения фантомов.

← →
Desdechado © (2006-06-23 13:12) [45]

Sergey13 © (23.06.06 12:49) [43]
Значит, нет. Следовательно, возможны читающие транзакции. Что подтверждает и цитата из Кайта.
Т.о. остается выяснить, если я не установил специальных параметров транзакции, и просто сделал 100 SELECT"ов, не отключившись от базы, то что, я заблокировал все эти данные?! Чтой-то не верится...
А если не заблокировал, то эту транзакцию я могу держать сколь угодно долго, и другим юзерам от этого плохо не будет. Собственно, с этого я и начал.

← →
Sergey13 © (2006-06-23 13:27) [46]

2[45] Desdechado © (23.06.06 13:12)
>Следовательно, возможны читающие транзакции.
Я бы вместо "читающие транзакции" сказал "ничего не меняющие сеансы". Ибо транзакцию, в моем понимании надо подтверждать (или отменять), а "ничегонедеоание" этого не требует.
Естественно они ничего не блокируют. В Оракле даже "писатели" не блокируют "читателей". Единственное - под сеанс выделены ресурсы сервера и пустопорожнее их удержание не есть особо хорошо, но это уже другая пестня.

← →
ZeroDivide © (2006-06-23 13:31) [47]

> Reindeer Moss Eater © (23.06.06 11:29) [29]
>
> Правильный ответ надо искать в логике работы с данными конкретной
> предметной области. а не среди множества усвоеных с опытом
> правил и аксиом.

Абсолютно согласен. В IB/FB кусроры данных открываются и закрываются в контексте транзакции. В Oracle при Commit курсоры не закрываются, они либо читают последние подтвержденные изменения, либо читают последние неподтвержденные изменения в контексте автоматически открытой (Insert, Update, Delete) транзакции.

Ситуация:
Select <Редактирование пользователем> Update Commit
Вполне нормальная

А вот
Update <Редактирование пользователем> Update Commit
Действительно скушает память, но и только... На производительность это почти никак не повлияет.

← →
evvcom © (2006-06-23 13:45) [48]

> <Редактирование пользователем>

Это что такое? Чем отличается от Update? Не понял мысль.

← →
Sergey13 © (2006-06-23 13:50) [49]

> [48] evvcom © (23.06.06 13:45)
> > <Редактирование пользователем>
>
> Это что такое? Чем отличается от Update? Не понял мысль.

Это размышления пользователя - ту би, или, блин, нот ту би. 8-)

← →
Desdechado © (2006-06-23 14:14) [50]

Sergey13 © (23.06.06 13:27) [46]
> Я бы вместо "читающие транзакции" сказал "ничего не меняющие сеансы".
Т.е. я оказался прав. А проблемы только в разной терминологии.

> Ибо транзакцию, в моем понимании надо подтверждать (или отменять),
> а "ничегонедеоание" этого не требует.
А в моем: транзакция - это любое логически завершенное обращение к БД. Чтение - это не "ничегонеделание", это тоже обращение, т.е. транзакция.

← →
evvcom © (2006-06-23 14:18) [51]

> [50] Desdechado © (23.06.06 14:14)
> Т.е. я оказался прав.

Как говорил один великий лекарь,
Пациент скорее жив, чем мертв (с) Буратино
я скажу, что ты скорее прав, чем не прав. :)

← →
Sergey13 © (2006-06-23 14:28) [52]

2 [50] Desdechado © (23.06.06 14:14)
>А в моем: транзакция - это любое логически завершенное обращение к БД.
ИМХО, тут неправильно. Логин в БД - это тоже обращение к БД. Оно логически завершенное или нет?
Транзакция - это операция, переводящая нечто из одного согласованного состояния в другое согласованное. Если в неком процессе рассогласования нет как такового, то и транзакцией я бы этот процесс не назвал.

update mytable set myfield = 1
where myfield = 1
рассогласования нет как такового ;)

Из того-же Тома Кайта:
Основное назначение транзакций в базе данных — переводить ее из одного согласованного состояния в другое. При фиксации изменений в базе данных гарантируется сохранение либо всех изменений, либо ни одного. Более того, выполняются все правила и проверки, обеспечивающие целостность данных.
Транзакции базы данных обладают свойствами, сокращенно называемыми ACID
(Atomicity, Consistency, Isolation, Durability). Вот что означают эти свойства:
- Неделимость (Atomicity). Транзакция либо выполняется полностью, либо не выполняется.
- Согласованность (Consistency). Транзакция переводит базу данных из одного согласованного состояния в другое.
- Изолированность (Isolation). Результаты транзакции становятся доступны для других транзакций только после ее фиксации.
- Продолжительность (Durability). После фиксации транзакции изменения становятся постоянными.

А теперь вопрос: каким боком выделеное жирным имеет отношение к select-ам?
:)

точнее, наоборот, каким боком селекты имеют отношение к выделеному жирным. :)
вобщем, я считаю, что транзакции только на чтение - лишняя сущность, в подавляющем большинстве случаев.

2 [53] Val © (23.06.06 14:33)
>рассогласования нет как такового ;)
Его нет логически, по факту так сказать. Физически оно есть. Просто новое значение совпало со старым - частный случай.

> [54] Danilka © (23.06.06 14:40)

Я эту фразу и не стал цитировать, а прочел немного ниже и нашел [44]. Хотя если подумать, то Согласованность (Consistency) все же имеет отношение к селекту, которое и раскрывается в [44]

> [58] Val © (23.06.06 15:00)

Да я тоже забыл смайлик вставить, в знак того, что понял это как шутку.
Исправляюсь. 8-)))))))))))))))

Мне кажется информация из Тома Кайта касается не читающих транзакций, а уровня изоляции, с которым в оракле мало кто играет.
Таким образом ссылка на Тома Кайта в пользу существования читающих транзакций не корректна.
Если отбросить теоретическую шелуху, то транзакция в оракле начинается с первого изменения в БД и до коммита или роллбэка.
ситуация :
insert into Table1 <Пользователь ушел на обед> insert Table1 commit
приведет не только к съеданию ресурсов и разбуханию роллбэк сегмента (или чем его там в девятке заменили, но суть та же осталась), но и к блокировке на изменение таблицы Table1. Можете проверить сами. Читать, есно, из таблицы Table1 можно будет, но чтение будет идти из роллбэк сегмента (без учета добвленной записи), что тоже некузяво.

Задачу автора, если он ее нормально озвучит, наверняка можно решить без использования висячих транзакций. Правда, возможно понадобиться создать дополнительно временные таблицы.

> но и к блокировке на изменение таблицы Table1

Ну не так... :( Таблица не лочится. Лочатся только записи, которые апдейтятся. Соответственно с инсертом, вообще ничего не залочится, за исключением случая, если применяются пользовательские блокировки.

> evvcom © (23.06.06 15:18) [61]

Блокировки возникают, если есть коллизия.

Например :

t1 (
ID, Name
)
на Name висит уникальный индекс.

Из первой сессии
insert into T1(ID, Name) values (1, "Вася");

Из второй сессии
insert into T1(ID, Name) values (2, "Петя"); -- пройдет
insert into T1(ID, Name) values (3, "Вася"); -- зависнет до коммита или роллбека в первой сессии.

Читаться будет при любом раскладе.

set transaction read only - и имеем висячую транзакцию в статусе active, и до коммита/роллбэка DML вызовет ошибку
только вот зачем это надо - непонятно, потому как непонятно что вообще надо :)

> [62] ANB © (23.06.06 15:31)

Да, про такой случай запамятовал.

> [63] Petr V. Abramov © (23.06.06 15:32)

Сейчас выполнил:
set transaction read only; select * from dual;
никаких зависаний. Что имелось ввиду? И по Кайту вроде все понятно, для чего это.

Похоже, автора забили интеллектом или запугали.
А, может, он последовал совету запостить на sql.ru и отгрести тумаки :)

> evvcom © (23.06.06 15:47) [66]
а кто сказал, что я пытаюсь кого-то удивить :) просто народ 20 постов решал, бывают readonly транзакции, или нет :)

> [68] Petr V. Abramov © (23.06.06 15:56)

а....а.... Так вот это к чему :-)

> [67] Desdechado © (23.06.06 15:49)

Да, видимо, огрёб, унести не может. :)

readonly транзакции бывают.
других транзакций на чтение в орокле не бывает.
:)

Ну ка дай ссылочку на ветку . . .

не справился sql.ru, не оправдал высокое доверие :)

← →
Sergey Masloff (2006-06-23 19:40) [74]

Petr V. Abramov © (23.06.06 17:17) [73]
>не справился sql.ru, не оправдал высокое доверие :)
Кто б сомневался. А на самом деле никаких особых проблем с длительными транзакциями в оракле нет, так что сколько по бизнес-логике нужно столько и держать. Ситуации разные бывают, и на всякую ситуации свои механизмы. А легенды что хорошие транзакции-короткие транзакции оставим сторонникам религий и пользователям СУБД для которых это проблема ;-)

Помогите найти доводы для начальства Найти похожие ветки