 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 04 Jan 2003 18:15:14 To : Tolik Tentser Subject : Re: Синхpонизация доступа к БД -------------------------------------------------------------------------------- Hello, Tolik Tentser! You wrote to Vladimir Pavlikov on Mon, 30 Dec 2002 16:27:44 +0000 (UTC): >> Hе целостности данных, а осмысленности работы с ними. Если две (или >> больше) транзакции почти одновременно модифицируют одни и те же поля >> одной записи - результат будет определяться их [случайной] >> последовательностью, TT> Ой. >> причем все модификации, кроме последней, будут бессмысленными. TT> Ой. >> А конечный результат - до пере- >> селекта - неизвестным. И это можно предотвратить _только_ адми- >> нистративными способами TT> Владимир, но будь же справедливым. Просто это (в отличие от OLTP & TT> OLAP одновременно) - задяча, естественным образом разрешаемая TT> блокировками, и плохо работающая на версиях. Hу бывает, что иногда TT> все операции (в т.ч. и чтения) надо сериализовать, совершенно это TT> типовая ситуация при работе, например с заказами и резервированием TT> товара, перечислениями денег. TT> Зачем на консерваторию валить - просто вот в этой архитектуре оно не TT> очень удобно. Hаверн всё же и в ней есть методы работы с такими TT> ситуациями. Складывается устойчивое и неприятное ощущение, что у тебя немедленно сносит крышу не только при приближении к vs теме, до даже и при раз- говоре на _совершенно другие_ темы (как в данном случае), если вдруг тебе что-то примерещится :( По буквам : "две (или больше) транзакции почти одновременно модифицируют одни и те же поля одной записи" может привести либо к перекрытию транзакций, либо нет (короткие - разошлись по времени). В этом, втором случае, они успешно все закоммитятся. При этом я утверждаю : 1. Какая информация в _действительности_ содержится в записи после этой серии транзакций определяется _только_ переселектом. 2. Уже поэтому такая технология работы совершенно бессмысленна, ибо все транзакции, кроме последней, избыточны (как и работа пользо- вателей с ними). 3. Результат абсолютно не зависит от архитектуры сервера, т.е. тут (как и всегда в этой теме) - "пальцем в небо". Впрочем, это верно и для первого варианта (перекрытия) - после первого успешного коммита остальные транзакции идут лесом. Иди проспись :) --------------------------------------------- Владимир Павликов. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/6488af06b8e6.html, оценка из 5, голосов 10
|
|
|