Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2004.02.25;
Скачать: [xml.tar.bz2];

Вниз

Проверка на клиенте?   Найти похожие ветки 

 
Evgen   (2004-01-29 19:10) [0]

Уважаемые мастера Delphi помогите советом плиз...
Классическая задача:
Есть склад,
2 клиента создают одновременно расходную накладную, при этом обращаются на склад за одной и той же позицией, пока документ не создан, изменения на складе не произойдут, и другие клиенты их не увидят, но каким образом второму клиенту узнать, что первый уже выбрал для себя эту же позицию, и взял себе несколько единиц товара, но ещё не создал документ.?
таймер? Временная таблица?


 
hirlik   (2004-01-29 19:48) [1]

Разберитесь с уровнем изолированности транзакций


 
Sergey_Masloff   (2004-01-29 19:51) [2]

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


 
Evgen   (2004-01-30 13:11) [3]

Да, этот вариант я рассматривал, но предположим, что я выбрал пессимистическую блокировку, клиент просто может повиснуть и у меня навсегда позиции окажутся заблокированы? Именно в этом и суть моего вопроса.
P.S. Оптимистический вариант отпадает, т.к. задача оперативная.


 
Deniz   (2004-01-30 13:29) [4]

А если через вторую транзакцию в другую таблицу записать что-то вроде ИД будущего док-та(позже поясню для чего и откуда), ИД Товара, Кол-во, ДатаВремя блокировки(можно по default на сервере). И остатки на складе считать с учетом этой таблицы, причем определить время(например 1 час), на которое часть товара блокируется, и по прошествии этого времени, просто игнорировать запись. В это время клиент, который начал заполнять документ(часа то ему хватит?) заносит ИД будущего док-та, ИД и кол-во товара в вспом. таблицу, при удачном проводке документа снимает со склада кол-во и удаляет запись из всп. таблицы. Если клиент подвис, то через час эта запись уже никому не помешает, а ночью :))) чистить вспю таблицу! Не совсем конечно, но ... может будет толчок к новым мыслям :)


 
Reindeer Moss Eater   (2004-01-30 13:42) [5]

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


 
Zz_   (2004-01-30 14:05) [6]

>>Если рукавиц на складе осталось меньше, чем запрошено в
>>документе - откатывай транзакцию

Хватай сколько есть и коммить, пока другие не увели



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2004.02.25;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.46 MB
Время: 0.031 c
11-79687
grumbler
2003-06-04 21:49
2004.02.25
Хочу просто русский проект...


3-79572
Игорь
2004-01-29 14:32
2004.02.25
ADOConnection с *.dbf


4-80370
SkyRanger
2003-12-16 04:05
2004.02.25
Проблема с ХР


1-79957
WebErr
2004-02-13 18:09
2004.02.25
Работа с указателями в C и Pascal !!!


1-80006
romeo
2004-02-13 10:55
2004.02.25
ExtCreatePen и динамичский массив с описанием типа линии





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский