Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Представим себе вокзал. Несколько окошек, где продают билеты. Каждая транзакция - продажа партии билетов. Как проходит этот процесс мы все знаем. Подходим к окошку и говорим - мне 2 билета до Москвы. И начинается... транзакция. Заканчивается она лишь тогда, когда внесены все паспортные данные и деньги за билеты получены. а теперь, предположим что вы - отправляете в Москву группу туристов. Скажем так - человек 30...Т.е. я хочу сказать что транзакция может получиться очень длинной. А билеты - ресурс ограниченный. Может не хватить. Слеловательно билеты для группы должны быть заблокированы в начале транзакции. Подобные задачи возникают довольно часто. Например при продаже акций или в процессе набивки накладной Задача: 1) Продажа проходит одной транзакцией 2) Продажа (транзакция) растянута во времени (до получаса) 3) продавать билеты на один и тот же рейс могут одновременно из нескольких окошек. Для блокировочника - все понятно, решить задачу очень легко. А как будет выглядеть решение для версионника? т.е. я имею в виду Оракл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 11:47 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Организуйте топик для ОРАКЛА, так быстрее будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:01 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanА как будет выглядеть решение для версионника? т.е. я имею в виду Оракл? На Оракле это сделать невозможно!!! Написал бы структуру БД. Билеты ведь не только по количеству учитываются, но и по местам. Например можно быстро "застолбить" нужные места в нужном количестве признаком "зарезервировано". После ввода всей инфы - поменять статус на "продано". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:07 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
select for update..? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:08 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 Серега Разве Оракл не лучшая СУБД для ОЛТП задач? День длинный, может кто-нить, чё-нить и предложит, а мы посмотрим ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:14 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanДень длинный, может кто-нить, чё-нить и предложит, а мы посмотрим ... Я тебе через 20 минут предложил, чем не ндравится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:29 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
СерегаЯ тебе через 20 минут предложил, чем не ндравится? Это не решение а отмазка.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:30 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Слишком сильно усложнять задачу не будем начнем с этого: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:36 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanСлишком сильно усложнять задачу не будем начнем с этого: ИМХО, твоя таблица больше смахивает на отмазку, чем мое предложение. Продай мне по твоей структуре 5 общих, 3 плацкартных, 2 купейных и 1 СВ билет. Тут и Оракл сдохнет наверное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:47 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 gardenman Тебе если для диплома - тогда за бабло надо бы, за так голову ломать над красивыми решениями неохота никому. А если для того, чтобы работало - то Серега тебе уже предложил единественное правильное решение. Причем и для MS SQL и для Оракла. И еще подсказка - транзакции тут ни при чем. Если конечно нужно самое уродское решение - тогда используй транзакции, вешай всю систему. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:48 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Серега gardenmanСлишком сильно усложнять задачу не будем начнем с этого: ИМХО, твоя таблица больше смахивает на отмазку, чем мое предложение. Продай мне по твоей структуре 5 общих, 3 плацкартных, 2 купейных и 1 СВ билет. Тут и Оракл сдохнет наверное. Нет, это не отмазка...поверь, решение есть. Не хочешь торговать билетами?... Давай тогда торговать акциями. Обыкновенными неименными привелигированными. Можно поработать на складе. Предположим у нас есть 100 ящиков какого-то товара. И в разных филиалах его продают. сначала - оформление документов (выписка фсяких накладных и пр...). И чтоб пока документы оформляются - наши ящики не ушли кому-нить другому. Все - одной транзакцией. В общем - условия - те же... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:55 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
tygra2 gardenman Тебе если для диплома - тогда за бабло надо бы, за так голову ломать над красивыми решениями неохота никому. А если для того, чтобы работало - то Серега тебе уже предложил единественное правильное решение. Причем и для MS SQL и для Оракла. И еще подсказка - транзакции тут ни при чем. Если конечно нужно самое уродское решение - тогда используй транзакции, вешай всю систему. -- Tygra's -- Я свой диплом получил в 1988 году....((( Вообще-то тогда еще этому не учили. А сейчас столько много умных, после интститутов.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 12:56 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторЯ свой диплом получил в 1988 году....((( Вообще-то тогда еще этому не учили. А сейчас столько много умных, после интститутов.... Там и сейчас этому не учат :) Так что не переживайте - все в одинаковой ситуации, хоть сейчас, хоть тогда, хоть с дипломом, хоть без. А с терминами все-же не заморачивайтесь - делайте так, как удобно, как лучше. Главное чтобы работало. И не важно, как оно там называется и кем кому приходится :) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 13:02 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanНет, это не отмазка...поверь, решение есть. Не хочешь торговать билетами?... Давай тогда торговать акциями.В общем - условия - те же... Фиг тебе - те-же? Отсюда и проблема у тебя растет. 8-) Даже в торговле ящиками товара есть варианты. gardenmanПредположим у нас есть 100 ящиков какого-то товара. И в разных филиалах его продают. сначала - оформление документов (выписка фсяких накладных и пр...). И чтоб пока документы оформляются - наши ящики не ушли кому-нить другому. Все - одной транзакцией. Исходи из того, что если ящики кончаются - это плохо (недоработка снабженцев), и скорее всего будет встречаться не очень часто. Далее. С чего ты решил что твое общение с БД заканчивается с концом транзакции? Отнють. Если транзакция прошла, то да. А если произошла искл.ситуация (поставь например ограничение на количество>=0 и ты ее получишь) и произошел откат, то никто не запрещает тебе в программе выяснить причину отката (опросить "свежее" количество), дать исправить документ юзеру и попытаться сохранить снова. Или, на худой конец, вывести юзеру месадж - "Извини, братан, кто первый встал того и тапки". И тут кстати вообще по барабану, ИМХО, версионник или блокировочник. Нюансы могут быть, но общая схема та-же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 13:14 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Дорогой Tygra! Смысл того, что здесь написано совсем другой. И я имел в виду совсем не то, о чем ты подумал. Я хочу сказать что существует класс задач, для которых Оракл не катит . Вот как ты думаешь, почему кластерные реализации от Оракла и от IBM такие разные? Ведь совсем не потому, что Оракл круче и совсем не потому, что IBM не могут как Оракл. А потому, что в силу своих архитектурных особенностей JОракл по-другому просто не может ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 13:14 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 Серега Вот-вот.... если мы не можем это запрограммировать, то давайте изменим процесс так, чтобы это можно было сделать... Хороший способ решать вопросы...делать вид, какбудто их нет...(С) Макаревич ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 13:17 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanСмысл того, что здесь написано совсем другой. И я имел в виду совсем не то, о чем ты подумал. Я хочу сказать что существует класс задач, для которых Оракл не катит . Конечно!!! Но практически все задачи связанные с БД, не входят в этот перечень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 13:18 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanВот-вот.... если мы не можем это запрограммировать, то давайте изменим процесс так, чтобы это можно было сделать... Переведи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 13:20 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Эта задача как раз из тех, для которой катят все СУБД, у которых есть транзакции. Можно и совсем без транзакций, но это несерьезно будет :) Так что вас так смутило то в задаче? Вам предложено решение. Вы толи его не принимаете, толи еще что- напишите, в чем проблемы. Вами пока не предложено ни одного решения. Кстати, с ящиками та же беда - не надо тут никаких транзакций, транзакции с клиента - это зло! -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:13 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
имеется запись insert into routes (route_num,departure_dt,tickets_cnt,tickets_sold) values ('C100','31.12.2004',1000,950) видно, что было 1000 билетов, 950 из которых - продано.=> осталось 50 билетов. Иммется два окошка. К первому подходит гражданин, и пытается 2 купить билета. Кассарша начинает транзакцию, говорит: select ... for update. Запись - блокирована. К другому окошку подходит другой мэн...и просит 2 билета на тот же рейс. Ну и другая кассирша тоже делает select ... for update на ту же запись... ну и как им быть? Ждать пока кассирша в первом окошке не расчитается с клиентом и не сделает commit? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:25 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторвидно, что было 1000 билетов, 950 из которых - продано.=> осталось 50 билетов. Иммется два окошка. К первому подходит гражданин, и пытается 2 купить билета. Кассарша начинает транзакцию, говорит: select ... for update. Запись - блокирована. К другому окошку подходит другой мэн...и просит 2 билета на тот же рейс. Ну и другая кассирша тоже делает select ... for update на ту же запись... ну и как им быть? Ждать пока кассирша в первом окошке не расчитается с клиентом и не сделает commit? Вам уже сказали решение без транзакций - именно то, которое нужно. Что вы к транзакциям прицепились? -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:29 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Если у вас уже есть та структура, которую вы приводите, и менять ничего нельзя - тогда решения нет, пусть все пассажиры ждут, пока первый кассир в тувалет сходит и освободит таблицу :)) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:30 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 tygra Пожалуйста, не заходи в этот топик, кругом столько других интересных... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:32 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman Ждать пока кассирша в первом окошке не расчитается с клиентом и не сделает commit? А, при такой схеме , зачем блокировать вообще, если у нас еще 50 билетов, а берут обычно не более 5? А если бы было 950 свободных и очередища? Наверное поезд уедет прежде, чем один вагон обилетят. gardenmanНет, это не отмазка...поверь, решение есть. Ну не томи уже, опубликуй. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:39 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Продолжаем.... Усложним задачу... пусть все будет без транзакций... К первому окошку подходит руководитель тургруппы - и заказывает 30 билетов... Ну и естественно начинает оформлять их по очереди... Пока они то да се...по одному билету оформляли, на других вокзалах и в других окошках скупили 25 билетов.. ну и 5 билетов руководителю тургруппы не хватило... Обидно...А нужно туристов скопом везти.... Придется сдавать купленные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:40 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Решение: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:43 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
причем работа проходит в режиме Uncommited Read (грязное чтение) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:44 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman Можно поработать на складе. Предположим у нас есть 100 ящиков какого-то товара. И в разных филиалах его продают. сначала - оформление документов (выписка фсяких накладных и пр...). И чтоб пока документы оформляются - наши ящики не ушли кому-нить другому. Все - одной транзакцией. В общем - условия - те же... Бред. При чем здесь транзакции? Не видел ни одного заказчика, который описывая требования к системе упомянул бы условие "Все - одной транзакцией". А вот условие "что бы ящики не ушли" решается элементарно при правильном проектировании. Например введением понятия "резервирование", которое может происходить еще до выписки документов. -- http://talk.ru/forum/talk.ru.accounting.development ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:49 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
системы всякие бывают...)) требования разные... но подходы к решению проблем могут быть одними и теми же... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:53 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Ты зря не привел скрипт создания инстанса с включением в пост всех скриптов Оракла. Было бы нагляднее. Ответь мне на вопрос - а где учет мест? Ведь тому мужику, что насилует кассиршу, надо плацкартные НЕБОКОВЫЕ. А если их назавтра нет, то он поедет послезавтра. причем работа проходит в режиме Uncommited Read (грязное чтение) Ты мне просто скажи - на каком вокзале это работает? В каком городе? А то вдруг я туда поеду. Предупрежден - уже вооружен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:57 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Вы еще про бронирование забыли. Это когда деньги еще не уплачены, а билеты уже формально проданы (то есть их нет в наличии в кассе). Значит ли это с точки зрения автора топика, что транзакция закончится только когда человек придёт и выкупит билеты реально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:00 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanсистемы всякие бывают...)) требования разные... но подходы к решению проблем могут быть одними и теми же... Странная задача на самом деле. В начале вы намекаете что сущьность места не нужна (едем в электричке?) достаточно кол-ва свободных мест в поезде, а потом очень долго забиваете паспортные данные (куда?). Т.е. система учитывает сколько свободных мест и какие паспорта едут в этом поезде? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:18 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
))) Ну уж нет, раздувать простой пример до решения для МПС я не намерен...)) так что решение с плацкартом и СВ с девушкой для Сереги - предоставим кому-нить другому. Ладно, более подробно, как это все работает: 1) К 1 окошку подходит гражданин и заказывает 600 билетов set isolation ur insert into locks values ('C100','31.12.2004',600,1) DB20000I Команда SQL выполнена успешно. гражданин сует кучу паспортов, бабки и ждет когда его оформят по полной программе. 2) Ко 2 окошку подходит другой гражданин и пытается заказать 500 билетов: set isolation ur insert into locks values ('C100','31.12.2004',600,2) SQL0438N Программа генерирует ошибку с текстом диагностики: "Too many tickets". SQLSTATE=75001 Срабатывает триггер BILocks, мэн получает отлуп по полной программе и уходит, а к окошку подходит следующий и заказывает 4 билета insert into locks values ('C100','31.12.2004',4,2) DB20000I Команда SQL выполнена успешно. --от автора: Код: plaintext 1. 2. 3. 4. 5. 6. 3) во втором окошке все напечатали, бабки приняли и делается: insert into sales (route_num,departure_dt,desk) values ('C100','31.12.2004',2) commit срабатывает триггер BISales, чтобы продать именно столько билетов сколько было заблокировано и срабатывает триггер AISales, который обновляет кол-во проданных билетов в routes. Тут же делается commit, поэтому таблица routes не блокируется надолго. А блокировки в таблице locks от 2 окошка на 4 билета снимается. --от автора Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. а в это время в 1 окошке все еще незаконченная транзакция по продаже 600 билетов все еще висит, нужное кол-во билетов блокировано... а тем временем 2 окошко может обслуживать следующего потенциального пассажира. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:25 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
теперь можете критиковать.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:26 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman))) Ну уж нет, раздувать простой пример до решения для МПС я не намерен...)) Так ты для детской пластмассовой ЖД что ли? Тогда пойдет. gardenmanтак что решение с плацкартом и СВ с девушкой для Сереги - предоставим кому-нить другому. Вот так всегда. gardenman1) К 1 окошку подходит гражданин и заказывает 600 билетов set isolation ur insert into locks values ('C100','31.12.2004',600,1) DB20000I Команда SQL выполнена успешно. гражданин сует кучу паспортов, бабки и ждет когда его оформят по полной программе. После ввода 599 паспортов система вешается и "спасает" ситуацию только комбинация из трех пальцев. В системе благополучно залочено 600 мест. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:39 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
увы... транзакция благополучно откатится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:42 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Поддерживаю Серегу :) И еще: автора в это время в 1 окошке все еще незаконченная транзакция по продаже 600 билетов все еще висит, нужное кол-во билетов блокировано... Объясните, зачем вам тут транзакция??? Общая, одна на все 600 билетов, зачем? Вы что, по-человечески, без транзакции, не можете спокойно зарезервировать 600 билетов для пластмассовой ЖД и потом оформлять их хоть три дня подряд? И еще автор-- Продаем именно столько билетов, сколько заблокировали Так вы еще их скопом продаете? Не по одному? А зачем такой гимор? А если придется сделать комбинацию из трех пальцев - ту, что постом выше - то и информация всех 599 паспортов улетит в ж.. это, в трубу? Круто! -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:47 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Ну я надеюсь, судя по всему, что Экспресс-2 (и 3) не по такой схеме делали, иначе бы вокзал дневное количество билетов месяц продавал бы -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:48 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Опять никто никого не понял... Или я никого не понял, но сделал следующие выводы: 1) Разделить понятия транзакций с СУБД и транзакций с кассиршой 2) Таблица с блокировками - кривая система резервирования Блокировки допустимы только во время проведения операций с базой. Взятие денег, ввод данных - не операция с базой, а операция с клиентом. Блокировки нужны более высшего уровня. Операция резервирования и операция реализации лежат в одной таблице, которая привязана к таблице с рейсами. Их различие ведется по статусу. На кол-во свободных мест стоит ограничение >0. Если кто-то захочит вставить лишнее - не выйдет. Сначала добавляем икс билетов в расход со статусом зарезервировано, триггером снимаем этот икс с таблицы со свободными местами. Затем кассир вбивает свою муть получает деньги и переводит статус в продано. Если при срабатывании триггера срабатывает ограничение, то кассир обламается с резервированием - и вбивать ничего не придется. Если клиентский комп отвалился, то тетка решает, вешать ли ей табличку "технический перерыв", то ли ждать разрешения проблемы связи. При возобновлении связи в первом случае она удаляет резерв, во втором доводит дело до конца. Если необходим учет разновидности мест(товарной сущности), то это надо соответственно отразить в предложенном варианте. Почему все бьются над одной и той же проблемой, и все время призывают в помощь уровни изоляции???!! И лень поискать на форуме. Здесь уже обсуждался похожий пример, только там был склад и выписывание товара, что по сути одно и тоже. Ссылку не дам, лень искать. Думайте, господа, над сущностью телодвижений "клиентов" и их взаимосвязью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 23:02 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 iLLer Правильно все понял - мы о том же и говорим с Серегой. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 11:36 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
"Усиленное решение". Я так понимаю единственная проблема была в триггере BILocks, дескать он может сработает не совсем так как нужно в конкурентной среде. Т.е. Я и Ёжик намекал на то, что всеже могут быть проданы лишние билеты (особенно если убрать CHECK CONSTRAINT AtCnt на таблице ROUTES). Конечно же я осознаю, что то, что сейчас здесь будет нарисовано не будет работать ни на одной из известных мне баз кроме DB2. Напишем хранимую процедуру на С++ в которой создадим именнованный мьютекс. Таким образом получится что инсертить в таблицу LOCKS (вместе со срабатыванием соответствующего триггера BILocks) в один момент времени может только один клиент. Makefile Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. reserve.def Код: plaintext 1. 2. reserve.sqx Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. таким образом чтобы заблокировать соответствующие билеты с 1000 станций (начать соответствующие транзакции, каждая из которых может кончится когда угодно, не мешая другим и при этом всё будет согласовано и ни каких лишних билетов на машине с Celeron 1300 в качестве сервера уйдет примерно 4 секунды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 11:37 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Я уже начинаю думать, что мы со слепым тут разговариваем - не видит человек ничьих постов, кроме своих, ну хоть ты тресни. Доктор....... Доооооктооооорррррр......................рррррр.....рррр..... :) авторНапишем хранимую процедуру на С++ в которой создадим именнованный мьютекс. Таким образом получится что инсертить в таблицу LOCKS (вместе со срабатыванием соответствующего триггера BILocks) в один момент времени может только один клиент. Инсертить всегда в один момент времени может только один клиент, особенно если он использует транзакцию. gardenman начать соответствующие транзакции , каждая из которых может кончится когда угодно, не мешая другим и при этом всё будет согласовано и ни каких лишних билетов на машине с Celeron 1300 в качестве сервера уйдет примерно 4 секунды Может вы все же объясните, что вы понимаете под транзакциями в данном контексте??? ============= Сам с собой человек разговаривает - круто, да? А зачем на форус обратился? Чтобы его гениальный алгоритм все увидели? Дык увидели, и даже прокомментировали.... Что же еще? -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 11:53 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman"Усиленное решение". Вообще существует ещё много интересных и не менее полезных занятий в этом мире, например изобретение вечного двигателя. gardenman Я так понимаю единственная проблема была в триггере BILocks, Не единственная, а первая попавшаяся на глаза . В Вашу синхронизацию как минимум надо включить оба ваши триггера на sales и и все возможные операции на routes, только тогда можно будет ожидать корректных результатов. Т.е. по сути Вы ВСЕ операции с базой данных над таблицами locks,sales, routes выстраиваете в очередь, т.е сериализуете ( как вам и говорил vc123) только не на уровне БД а на уровне OS, искусственно выделив из сериализации часть транзакции по вводу данных паспортов. Не проще ли выделить этот ввод в отдельную транзакцию и не мучиться изобретением велосипедов? tygra Я уже начинаю думать, что мы со слепым тут разговариваем - не видит человек ничьих постов, кроме своих, ну хоть ты тресни. Он же сказал уже: "Смысл того, что здесь написано совсем другой. И я имел в виду совсем не то, о чем ты подумал. Я хочу сказать что существует класс задач, для которых Оракл не катит." Его не интересует как "правильно и эффективно" решить реальную задачу, он хочет показать, что в такой кривой постановке её можно решить только на блокировочнике с грязным чтением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 14:03 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
В упор не вижу причин для: 1) Невозможности реализации на Oracle или любой другой SQL-СУБД. И даже не столько невозможности, сколько не профильности. Если у Вас будет один сервак и тыща касс, то многие СУБД могут загнуться. 2) Необходимости применения уровней изоляции (не блокировок, так как это понятие растяжимое). Необходимо разделить понятия транзакционности. То ли для Вас транзакция - это факт изменения данных в БД, то ли факт оформления покупки. И совершенно не обязательно одно натягивать на другое. 3) Необходимости применения синхронизации работы клиента (А какого черта Вы тогда вообще в СУБД лезете, еще чуть-чуть подправить, организовать хранилище данных в файле, и будет совсем автономная система, а вернее СУБД). СУБД для того и нужна, чтоб организовать надежный доступ многих страждующих к одним данным и она берет на себя задачу сериализации транзакций. Пора призывать модераторов закрывать эту тему. Ибо начальный вопрос потерян и не уместен в данном контексте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 22:41 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Его не интересует как "правильно и эффективно" решить реальную задачу, он хочет показать, что в такой кривой постановке её можно решить только на блокировочнике с грязным чтением. 1) Хотел бы увидеть почему моё решение неправильное. Пожалуйста - аргументы. Хотите сказать что оно не работает? Привидите такую последовательность действий над системой, когда результат будет не таким, каким я его ожидаю. 2) Почему моё решение неэффективное? У вас есть более эффективное? требующее меньшего I/O, меньших затрат на програмимирование, увеличивающее параллелизм? >Пора призывать модераторов закрывать эту тему У нас появился цензор? Меня записали в еретики? Сожжете на костре? 3) У каждой задачи существует множество решений, также, как существует множество людей. И увы, не нам решать имеют ли они право на существование. Теперь еще раз медленне и подробнее. Два пользователя хотят изменить в записи поле с остатком. пользователь А делает select for update nowait - блокирует запись. Пользователь Б также делает select for update nowait - и получает отлуп. Если он сделает просто select for update - то подвиснет до тех пор, пока А не сделает commit. Таким образом они редактируют запись по очереди . И от этого конечно не избавиться ни в одной системе. Но в отличие от версионника, блокировочник может построить очередь из таких незавершенных запросов (транзакций) и, спрогнозировав сколько билетов осталось в кассе ( несмотря на то, что еще не все транзакции закоммичены ) сказать - можете не занимать очередь, вам все равно не хватит. Но если хотите испытать судьбу - подождите. Может вам и достанется. Или, например в другом случае, не просто дать отлуп на select for update nowait, а сказать - знаете, а эту запись редактирует сейчас Вася Пупкин, который сидит этажом выше, и хочет списать со счета 50 баксов, на счете останется еще 100 баксов. И, если вы хотите снять в пределах этих ста баксов - то пожалуйста - путь свободен. Если больше - то извините...(( За сим прощаюсь с вами. Всем удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2004, 11:24 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 gardenman ИМХО. Все твои ухищрения основаны на желании открыть транзакцию при обращении пасажира и закрыть ее после ввода 600 документов. Я тебе в самом начале описал как можно сделать в системах с высокой конкуренцией за данные. Просто для этого надо продумывать соответствующую структуру данных. Извращаться на хреновой (гипотетически упрощенной и отвлеченной от конкретной задачи) структуре с уровнями изоляции конечно можно, но непродуктивно. Опять же повторюсь - ИМХО . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2004, 12:04 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
to gardenman: 1) Никто не говорит, что Ваше решение неправильное. Вообще в жизни нет такого понятия, как правильно. 2) На счет меньших затрат на программирование - это точно. В Вашем варианте Вы делаете работу (по программированию), которую должна выполнять СУБД. 3) Я не цензор, это мое мнение 4) Все имеют прваво на существование 5) Также медленно: к чему вообще селект? В том смысле зачем Вам селект в одной транзакции с апдейтом? Первая транзакция: селект состояния по билетам, далее по желанию вывод на экран, сохранение в файл, распечатка, отсылка и т.д. Вторая: клиент посылает апдейт на изменение значения доступного кол-ва либо добавляет в систему документ о проведении операции резервирования, которая влечет изменения статусов доступности. В зависимости от реализации. Если вторая транзакция вернулась с ошибкой, то все ясно, мест нет. И можно сразу смело посылать покупателя, т.к. мест нет. Если места есть, то вбиваются детали и переводится состояние из "резерв" в "продан". Поднимитесь вверх и медленно прочтите мое предложение о реализации системы резервирования. Я уже это писал. И не только я. А с прогнозированием это Вы загнули. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2004, 12:49 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Да не слышит человек ни одного другого, отличного от его самого, мнения и решения. Придумал кошмар ночной и радуется до смерти. До смерти - это потому, что помрут все с такой реализацией. Ну как не понять, что обычным резервированием дело решается - не знаю. Без открытых висячих транзакций, грязных чтений и т.д. Ээээхххххххх -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2004, 14:46 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Хорошие вы все ребята, душевные.... Я сначала было подумал не отвечать... но блин вчера было так скучно и тоскливо в форуме... А вообще чем попусту сотрясать воздух (а ля тигра) я предпочитаю сначала подумать, а потом дать аргументированный ответ. Для начала несколько ситуаций: 1) Студент вытаскивает на экзамене говорит препаду: 13 билет, но отвечать я буду на 1 билет, потому, что я только его выучил 2) Заказчик приходит к подрядчику и говорит: вот нужно написать такую-то систему, можете ее реализовать на Оракле. Подрядчик - конечно можем...так что тут у Вас? а.. отлично, мы беремся, вот только реализация будет на MSSQL и вот это и это вы как-нить сами... 3) Если кто-то расписался в своем бессилии доказать теорему Ферма, то не проще было бы поменять вообще эту теорему, так сказать изменить условия задачи? Ситуация из жизни, с которой я сталкиваюсь ежедневно на работе: представляете (сразу говорю, автор не я!!!!) у нас параметры в ХП передаются через запись в постоянной таблице!!! А что это значит? То, что если человеку взбредёт в голову войти под своим своим логином с двух компов, то получится конфликт параметров! Рассмотрим подробнее ситуацию с резервированием. Сия ситуация означает, что транзакций в системе будет несколько. Одна с резервированием, другая - собственно с продажей. Следовательно записи на резервирование нужно как-то идентифицировать. Варианты: по имени пользователя, по номеру сессии, по коду терминала. 1)По имени пользователя: если это так, то с двух терминалов под одним и тем же именем не зайти - конфликт параметров ХП (смотрите ситуацию, описанную абзацем) 2)По номеру сессии: в случае глюка/отсоединения терминала мы теряем номер сессии, придется каким-то образом оперативно чистить зарезервированные билеты.(у Оракла ведь есть триггер на закрытие соединения? в любом случае у MS такого точно нет). А как тогда быть с внесенными вами данными по 599 паспортам? *я читаю внимательно все что вы пишете, и ищу контраргументы*. 3)По коду терминала: та же самая ситуация что и по номеру сессии. Знаете, ну как-то влом писать сборщик мусора, который в тоже время должен отрабатывать достаточно оперативно. Намного более дешевое (с точки зрения I/O) и простое решение - просто откатить транзакцию. Вы думаете задача представленная здесь - единственная в своем варианте? Есть еще одна задачка над которой все думают и все решают по-совему. Нужно зачислить на счета зарплату 100000 человек. Предположим в компе уже имеется этот список в какой-то таблице. Хотите пообсуждать как будет выглядеть такое решение? С учетом, что в системе работает сразу несколько сотен юзеров? Как сделать так, чтобы все отработало в приемлемые сроки с минимумом накладных расходов? Или, например, как сделать так чтобы эта операция была распараллелена между несколькими процессами и количество конфликтов было бы минимальным? Ситуация из жизни (у меня на работе, делал не я ). Идет прием бланков строгой отчетности (БСО). Имеется документ на 20000 бланков. У каждого бланка свой индивидуальный номер. Бланки должны быть приняты одновременно (документ-то один! сервер Sybase ASE). Рузультат: После небольшого скандала документ решили разбить на 4 по 5000. Понятное дело - просто криво спроектированна реализация. А как бы вы решали эту задачу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 13:59 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Задачка специально для tygra, как для любителя MSSQL: Предположим, у нас имеется некий набор договоров. Над определенной группой договоров мы должны провести некую группу однотипных операций, например - банальное расторжение. Задача - Оператор в гриде на своем рабочем месте помечает эти договора (например заносит их id во временную таблицу) а затем передает этот список в ХП, которая все их закрывает. Затем дополняет список этих договоров еще некоторым количеством договоров (отбирая их по какому-нибудь критерию), а затем - передает их другой ХП, которая их переоформляет на новых условиях. Затем чистит пометки и повторяет операцию снова. Как это будет выглядеть на MSSQL? Понятное дело что временная таблица должна быть создана не в какой либо ХП, а самим приложением. И это должна быть не таблица с ##, потому как в этом случае она будет доступна всем сесииям. А тепрь еще наложим условие, что приложение у нас написано,исходников нет, и код мы можем только на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 14:30 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторНо в отличие от версионника, блокировочник может построить очередь из таких незавершенных запросов (транзакций) и, спрогнозировав сколько билетов осталось в кассе (несмотря на то, что еще не все транзакции закоммичены) сказать - можете не занимать очередь, вам все равно не хватит. ^^^ это как :) что-же есть такое в блокировочнике чего не может select for update и оракловые пользовательские блокировки ? похоже я что-то грандиозное пропустил :) к стате а db2/mssql могут указывать сколько ждать на запросе, у оралового можно указать в секундах сколько ждать типа select ... for update wait 30 (точно синтаксис не помню) ? ЗЫ. МПС работает на SAP + oracle и как-то умудряется зарплату расчитать :) http://ru.sun.com/win/sales/transport/mps.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 22:58 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Бред. Хоть задачка и не для меня, скажу, что она из разряда: "Хачу, пнимаешь, на Луну, только чтоб на Жигулях, бензин был в качестве топлива, и без водителя". Такого не бывает. Либо на Жигулях, либо без водителя, либо на бензине, но не одновременно, всему есть предел. А то, что параметры в процедуру передаются через таблицу - это вообще отдельный разговор, который не связан с блокировками и транзакциями. И тем более с тем, как сохранять целостность в системе. Если Вы не можете решить одну проблему нормальным путем, не создавая себе при этом других, то это не значит, что нет таких решений, при которых не возникает других проблем. А про ситуацию с резервированием могу добавить: Если возникает необходимость сделать монопольный доступ к зарезервированым местам, то это необходимо сделать ("Хочешь быть счастливым - будь им"(с) Козьма Прутков). Только он организован не на системе блокировок в СУБД, а на более высоком уровне. Т.е. запись о резервировании принадлежит пользователю (сессии - не очень хорошо). Отвалился - никто твой резерв не возьмет. Включился - будь добр определи судьбу твоих резервов, либо сними (если клиент свалил), либо утверди (если клиент дождался), и только потом продолжай работу в штатном режиме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 23:07 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanСитуация из жизни, с которой я сталкиваюсь ежедневно на работе: представляете (сразу говорю, автор не я!!!!) у нас параметры в ХП передаются через запись в постоянной таблице!!! gardenmanСитуация из жизни (у меня на работе, делал не я ). Не хочу никого обидеть, но бывает ситуация, когда делал ты? Почитаешь тебя - вообще ничего сделать нельзя ни на чем. Чем тогда люди занимаются? Если у тебя возникает множество вопросов, то лучше спрашивать их отдельными топиками. И не объявлять заранее, что у тебя уже есть самое правильное решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 09:34 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Я даже и не знаю теперь, отвечать или нет? Оказалось, что я (да и все) тут продвигают MS SQL - хотя даже уже кричали, что в самомо начале топика предложено универсальное решение для любой БД, причем единственно правильное. авторРассмотрим подробнее ситуацию с резервированием. Сия ситуация означает, что транзакций в системе будет несколько. Одна с резервированием, другая - собственно с продажей. Точно. Только они короткие очень - 1. зарезервировать билеты 2. сделать продажу. Все, никаких ваших висячих транзакций. автор Следовательно записи на резервирование нужно как-то идентифицировать. Варианты: по имени пользователя, по номеру сессии, по коду терминала. Да как хотите - все зависит от того, как будут работать с системой автор1)По имени пользователя: если это так, то с двух терминалов под одним и тем же именем не зайти - конфликт параметров ХП (смотрите ситуацию, описанную абзацем) См. Предыдущий комментарий. Если входить можно только с одного места - то можно и так. автор2)По номеру сессии: в случае глюка/отсоединения терминала мы теряем номер сессии, придется каким-то образом оперативно чистить зарезервированные билеты.(у Оракла ведь есть триггер на закрытие соединения? в любом случае у MS такого точно нет). Несколько раз приводился готовый код для таких вещей. авторА как тогда быть с внесенными вами данными по 599 паспортам? Это как быть с внесенными вами 599 паспортами - у меня то нет одной большой открытой транзакции, я все эти 599 билетов с паспортами внес и продал . А вы все это потеряли автор*я читаю внимательно все что вы пишете, и ищу контраргументы*. Плохо ищите - совсем не то. автор3)По коду терминала: та же самая ситуация что и по номеру сессии. И те же самые комментарии. авторЗнаете, ну как-то влом писать сборщик мусора, который в тоже время должен отрабатывать достаточно оперативно. Намного более дешевое (с точки зрения I/O) и простое решение - просто откатить транзакцию. Ну раз в лом - об чем разговор. В лом и систему писать - нафиг надо? :) Вы уж тогда проще сделайте - при старте клиентского приложения открывайте одну транзакцию, здооооровенную, а при закрытии - коммит. А если вруг сбой - ну ничего, день потеряете, зато не в лом авторЗадачка специально для tygra, как для любителя MSSQL: Не вижу ничего такого в "задачке", что бы ее относило к MS SQL авторПредположим, у нас имеется некий набор договоров. Над определенной группой договоров мы должны провести некую группу однотипных операций, например - банальное расторжение. Задача - Оператор в гриде на своем рабочем месте помечает эти договора (например заносит их id во временную таблицу) а затем передает этот список в ХП, которая все их закрывает. Затем дополняет список этих договоров еще некоторым количеством договоров (отбирая их по какому-нибудь критерию), а затем - передает их другой ХП, которая их переоформляет на новых условиях. Затем чистит пометки и повторяет операцию снова. Как это будет выглядеть на MSSQL? Понятное дело что временная таблица должна быть создана не в какой либо ХП, а самим приложением. И это должна быть не таблица с ##, потому как в этом случае она будет доступна всем сесииям. Ну кто как хочет - кто через #t, кто по одному документу. авторА тепрь еще наложим условие, что приложение у нас написано,исходников нет, и код мы можем только на сервере. Так вы определитесь - или задачку решать или менять ничего нельзя. Или по-русски объясните, что значит и код мы можем только на сервере ? А кстати, что вас так смутило в этой так сказать "задачке"? Не смогли решить для MS SQL? ======== Итог: вы все-равно никого не слушаете и продолжаете применять длинные ненужные транзакции. Приводите какие-то странные примеры - толи в подтверждение своего решения (типа, вон еще хуже бывает), толи еще почему - не знаю. У вас есть какие-то проблемы? С Ораклом? С MS SQL? Так вы скажите прямо - расскажем, чего знаем. Чего странными "задачками" прикрываться? ЗЫ Ничего не понимаю................ -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 12:35 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanимеется запись insert into routes (route_num,departure_dt,tickets_cnt,tickets_sold) values ('C100','31.12.2004',1000,950) видно, что было 1000 билетов, 950 из которых - продано.=> осталось 50 билетов. Иммется два окошка. К первому подходит гражданин, и пытается 2 купить билета. Кассарша начинает транзакцию, говорит: select ... for update. Запись - блокирована. К другому окошку подходит другой мэн...и просит 2 билета на тот же рейс. Ну и другая кассирша тоже делает select ... for update на ту же запись... ну и как им быть? Ждать пока кассирша в первом окошке не расчитается с клиентом и не сделает commit? После первого селекта запись уже заблокирована, и ни в одной нормальной системе 2ая касирша не сможет обновить заблокированную запись, что не понятного? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2005, 15:39 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman Задача: 1) Продажа проходит одной транзакцией 2) Продажа (транзакция) растянута во времени (до получаса) 3) продавать билеты на один и тот же рейс могут одновременно из нескольких окошек. Ну это явно надуманная постановка задачи. Задача - продавать билеты, а не программировать транзакции. Представим всего один московский вокзал. 45 суток * 500 мест * 100 поездов = 2,25 млн мест, в день в среднем бронируется/продается 50000. 50000 / 24 часа работы касс / скажем, 3 минуты на операцию = 100 одновременно открытых транзакций. А теперь - смертельный номер - умножим это на количество вокзалов (или станций РЖД?! я туплю). Капец. Что-то слабо верится что какое-либо железо способно с этим справиться. Транзакции надо открывать на момент записи, только чтобы обеспечить отсутствие двойной продажи (ну и двойного резервирования тоже). ЗЫ. Я не продаю железнодорожные билеты. Я так, прикалываюсь. 3 минуты - из практики стояния в очереди за билетами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2005, 17:37 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Транзакции нужно открывать тогда, когда нужно и держать столько, сколько нужно по требованиям бизнеслогики. (С) Том Кайт (правда немного не точно, т.к. нет под руками первоисточника) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2005, 17:40 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Уважаемый Садовник, Извините за нескромный вопрос, Вы где работаете - или хотя бы кем? Оч. похоже, что основное Ваше занятие - разведение кактусов, а с SQL Вы решили поразмяться, шоб мозги на затухли. Достойное решение! Я извиняюсь за сей _грубый_ (не спорю) вопрос, точнее комментарий, так как он ответа не предпологает. Причина тому такова, что в 99% случаев либо нам деньгу плотять, за то что мы рожаем что-то, либо мы сами деньгу получить за свой труд надеемси. Ну 1% - так хобби, развлекалочка. Вот сей _проект_ развлекалочка и есть. Рожать надоть _работающие_ программы (плохо ли, хорошо ли - вопрос другой, хотя лучше, шоб хорошо...) _Неработающие рожать не надо, какие бы они красивые не были... Лирическое отступление Самая безошибочная программа - это та, что выдает "Hello, World". Она же и самая бестолковая, никому не нужна... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2005, 20:43 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanТранзакции нужно открывать тогда, когда нужно и держать столько, сколько нужно по требованиям бизнеслогики. (С) Том Кайт (правда немного не точно, т.к. нет под руками первоисточника) Хорошо бы привести критерии оптимальности решения, которыми автор процитированного руководствовался. Каюсь, не читал. Я соглашусь что Ваши идеи полностью соответствуют описанию бизнес-логики, приводимой Вами в описании "задания". Другое дело, что я пытаюсь довести до Вашего сведения, что imho описанная логика порочна и попросту неработоспособна в реальных условиях эксплуатации системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2005, 09:50 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
А ему пофиг, что его решение неработоспособно. Потому-что это его решение. А если какие-то ослы будут тут советовать, да еще пальцами тыкать - дык что на них отвлекаться, у гениев на это нет времени :(=) ЗЫ Если он все так пишет, то непозавидуешь заказчикам. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2005, 11:57 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
В результате таких пейсателей я неделю назад попал в презабавнейшую ситуацию, начали мне оформлять билет, когда закончили - сказало что мест уже нет( А по топику - в Oracle было предложено 2(два) работающих варианта "The CBO without stats is like a morning without coffee." T.Kyte ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2005, 18:32 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanДорогой Tygra! Смысл того, что здесь написано совсем другой. И я имел в виду совсем не то, о чем ты подумал. Я хочу сказать что существует класс задач, для которых Оракл не катит . Вот как ты думаешь, почему кластерные реализации от Оракла и от IBM такие разные? Ведь совсем не потому, что Оракл круче и совсем не потому, что IBM не могут как Оракл. А потому, что в силу своих архитектурных особенностей JОракл по-другому просто не может ) Несомненно, детей рожать оракл не катит. ЗЫ: катится всё, но с разной скоростью ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2005, 18:35 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Дорогой Hell, в моём случае такой вариант невозможен... Ты всегда у меня будешь с билетамами по самым льготным ценам и на самые разные направления...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 10:55 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2gardenman а что за кластерная технология есть у db2 ? чем эта "технология" принципиально отличается от dblink в оракле ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 12:09 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
про это уже много писалось в форуме с "сравнениях". Отличия принципиальные - у Оракла разделяемый диск (система хранения) у ДБ2 - просто ставится рядом еще одна машина,потом еще иеще.. и так до тысячи узлов. Короче ищите в сравнениях. Если реально нужно про кластера поспрашивать, то в форум по ДБ2. Некоторые юзают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 12:19 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
про различия shared nothing и ораклового shared disk архитектур я в курсе, я окуратно пытаюсь выяснить, чем оракловый dblink не аналог shared nothing "кластера" ? мне показалось вы сможете в 2х словах объяснить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 12:42 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Честно говоря до изучения dblink в Оракле я еще не дошел Если проводить аналогии то, как мне кажется: DB2 - fedefated server Oracle - dblink Sybase - proxy table Все это примерно одно и то же. Только в каждой системе разные навороты и несколько разные возможности. Везде можно написать запрос который будет использовать несколько источников данных (из разных баз данных) с разной степенью тормознутости (2-х фазный коммит в случае транзакции по нескольким таблицам из нескольких баз, который делается прозрачно). Но в случае кластера DB2 - это все одна база данных и ничего общего с двухфазными транзакциями. Это параллельная обработка одного запроса сразу несколькими компами, причем каждый работает со своей порцией данных (выделенной по хэш-функции). Т.е. это полноценное масштабирование и никакого pinging как в случае с Oracle RAC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 13:13 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторДорогой Hell, в моём случае такой вариант невозможен... Ты всегда у меня будешь с билетамами по самым льготным ценам и на самые разные направления...) Возможен вариант для любого сервера. ЗЫ А билет Hell никогда не оформит - затра..ется ждать окончания всех транзакций -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 15:31 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Ище одна мысль. А Вы уверенны, що у тети кассирщи Оракловый клиент будет? А я вот - нет, будет у нее ка-нить HTML форма. Тонкий клиент называется, между прочим. Послал запрос - получил новую форму. Ну и иде Ваши транзакции? CGI на сервере поднялси, в базу слазил, ответ сгенерил, усе транзакции и закрылись. Ну пусть даже и стоит Оракловый клиент у тетки. И склольки мы бум сессию открытую держать? Никакой мощи не хватит. Хватит, конечно, я щучю. Тольки все равно это очень _не_рациональное_ решение. Я даже на уровне одного загуска CGI освобождаю сессию, если все транзакции завершились. Может, это спорно, конечно - но держать сессию пол-часа ничего не делая - чересчур. Ездовых собак я видел, но ездовые коты - это чересчур. Трое из Простоквашино (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 17:57 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
>Я даже на уровне одного загуска CGI освобождаю сессию, если все транзакции завершились вот это точно не самое рациональное решение. Хотя для мелких систем с небольшой нагрузкой вполне прокатит в зависимости от длительности транзакции и количества транзакций в секунду :)) интересно было бы узнать о соотношении накладных расходов по старту сессии к собстенно работе с базой в такой системе. Вдруг окажется что половину ресурсов сервер тратит только на то, чтобы соединить/разъединить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 18:28 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman>Я даже на уровне одного загуска CGI освобождаю сессию, если все транзакции завершились вот это точно не самое рациональное решение. Хотя для мелких систем с небольшой нагрузкой вполне прокатит в зависимости от длительности транзакции и количества транзакций в секунду :)) интересно было бы узнать о соотношении накладных расходов по старту сессии к собстенно работе с базой в такой системе. Вдруг окажется что половину ресурсов сервер тратит только на то, чтобы соединить/разъединить? Много веб-серверов поставить - денег много не надо. А если это про SQL-сервер, то тут конечно вопрос, но все же думается что не так много и стоит новый коннект по сравнению с кучей висящих транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 18:35 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2gardenman у вас совсем древнии представления о веб-программировании :) даже php на mysql не открывает/закрывает конекции, а использует что-то типа пула конекций. также и cgi обычно через пул пишут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 18:50 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Yo! пишет: > у вас совсем древнии представления о веб-программировании :) даже php на > mysql не открывает/закрывает конекции, а использует что-то типа пула > конекций. также и cgi обычно через пул пишут. У уважаемого Yo! видимо представления о веб-программировании намного более опережают сегодняшний век, так как постоянные соединения у mysql (видимо именно это подразумевалось под умным словом "конекции") предназначены для экономии ресурсов сервера, а никак не для удержания текущей транзакции. А для всех cgi в рамках одной сессии держать открытой транзакцию на весь период длительности сессии? В чем смысл? Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 19:12 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
drmike У уважаемого Yo! видимо представления о веб-программировании намного более опережают сегодняшний век, так как постоянные соединения у mysql (видимо именно это подразумевалось под умным словом "конекции") предназначены для экономии ресурсов сервера, а никак не для удержания текущей транзакции. А для всех cgi в рамках одной сессии держать открытой транзакцию на весь период длительности сессии? В чем смысл? Posted via ActualForum NNTP Server 1.1 1. среднее время жизни программера у которого транзакции ждут юзерского инпута редко превышает 1 год , а юзеры народ злой, но справедливый. поэтому смысла объяснять почему не вижу т.к. кто не понимает, ему не долго осталось. 2. высказывание gardenman "Вдруг окажется что половину ресурсов сервер тратит только на то, чтобы соединить/разъединить " однозначно относится к конекции (connection), но никак не к транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 21:15 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Угу, разговор пошел в новое русло, пока еще без драки (что радует). Итак, имея некий опыт веб-прграммрования эдак 5-6 лет, и при этом еще оставаясь живым, имею наглость утверждать, что 1) Накладные расходы на connection не велики, про крайне мере для Oracle и MsSQL. 2) Проблема, которую создает долго висящая transaction, дороже. Верятность схватить блокировку и все повесить дороже выйдет. Извиняюсь за англицкие словечки - шоб понятнее было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 06:00 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushokНакладные расходы на connection не велики, про крайне мере для Oracle и MsSQL.Вы ошибаетесь. Можете сказать лишь следующее: "накладные расходы на connection не велики, про крайне мере для задач, с которыми я сталкивался на Oracle и MsSQL". Наш сервер работал на оракле и постгресе. Для обоих субд использовали persistent connections (через mod_perl), так как это давало большое увеличение производительности. Недавно я писал об этом . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 10:00 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Господа программисты, я не в коем случае не хочу утверждать что долговисящщие транзакции - это хорошо. Долго висящая транзакция у вас ассоциируется с долго висящей блокировкой (блокировка - это действительно ресурс). Но, однако, заметьте, точто я здесь предлагал - все совсем наоборот. Не ставте все с ног на голову. Несмотря на то, что, транзакция довольно продолжительная, блокировка - быстрая и безболезненная т.к. осуществляется лишь на очень короткий промежуток времени. И, честно говоря то, реализовать такое только средствами СУБД практически невозможно. Есть такая штука как SEQUENCE, или IDENTITY. Все знают что для ускорения выдачи этих значений они как-бы генерятся предварительно. Поэтому при сбое возникает identity gap, или разрыв в sequence. А ведь можно реализовать собственную версию sequence, которая этим не страдает. Опять же, без низкоуровнего программирования тут не обойтись. А скажите мне разве невозможно в случае зависания сессии, сначала считать ее незакомиченные данные, а затем сбросить зависшую сессию и продолжить ее работу? Возможно многое. И, как правило, такие прямолинейные действия на самом деле более работоспособны. Часто бывает так, что программист находит какой-то инструмент, изучает его и старается приспособить ко всему. Типа - мартышка и очки. Нельзя зацикливаться. Бог любит разнообразие. Короче - смотрите чуть шире. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 11:08 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
3 раза прочитал но чесно говоря совсем не вьехал, как транзакция в блокировочнике (db2 как я понимаю) длинная а блокировки быстрые, какие-то зависания у сессий - это сессия веб приложения имеется ввиду или сессия субд и что такое "зависание" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 11:33 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Я тоже первый раз прочитал - ничего не понял. Хотел второй было читать - но увидел, что Yo! и с 3-го не понял, то и я не стал читать больше. С ходу - каша какая-то, смешались в кучу люди, кони.... По коннектам: к MS SQL из asp.net можно через пул коннектов ходить, удобно однако. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 14:41 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 Леха Налоговый Я не ошибаюсь (я так думаю, вообще-то), однако, они _дейсвительно_ не велики. Хотя и зависят от многих факторов, в частности оракл и cgi на одном сервере или нет. Я таки про cgi толкую, на не про весь спектр задач, включаюших оракл. Хотя, полностью согласен, что использовнание долгоиграющей connection может увеличить производительность. Это с одной стороны, с другой увеличивается вероятность блокировки. Представте себе ситуацию, когда куча пользователей одновременно что-то делают - а результаты их работы постоянно суммируются и отображаются в одном месте (строчке в таблице). Тоесть каждый пытается менять эту строчку. Все процессы выстраиваются в очередь. Минимизация времени connection в этом случае спасает - отработал, отвались. 2 Садовник Таки тоже не понятно. Кады transaction началася, она по ходу дела выставляет блокировки. И блокировки будут сняты только в момент окончания транзакции. Сделать блокировку маленькой (по времени) - значит сделать маленькой саму transaction. Или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 00:38 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторПредставте себе ситуацию, когда куча пользователей одновременно что-то делают - а результаты их работы постоянно суммируются и отображаются в одном месте (строчке в таблице). Тоесть каждый пытается менять эту строчку. Все процессы выстраиваются в очередь. Минимизация времени connection в этом случае спасает - отработал, отвались зачем "отработал, отвались" ? отработал - закоммить транзакцию и дыши спокойно. Какие в ж..у блокировки после завершения транзакции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 01:17 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Отвались, потому что connection другим понадобиться может. Ресурс, таки. У а commit али rollback само собой разумеется, кудыж без него... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 05:02 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2andrushok почитайте все таки про connection pooling, отваливается веб клиент конекция остается просто отдается следующему веб клиенту. прерывая конекцию вы ничего не выйграете, только проиграете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 10:03 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushok2 Садовник Таки тоже не понятно. Кады transaction началася, она по ходу дела выставляет блокировки. И блокировки будут сняты только в момент окончания транзакции. Сделать блокировку маленькой (по времени) - значит сделать маленькой саму transaction. Или я не прав? Абсолютно правы. А теперь с другой стороны - блокировка ставится для того, чтобы всех клиентов построить в очередь к ресурсу. Я в своем варианте слегка "расширил" возможности этого подхода позволив клиенту считывать незакомиченные, но согласованные данные построив их в очередь перед семафором. Поэтому "лишний" билетик продать невозможно. А сам ресурс (запись с количеством доступных билетов) блокируется и освобождается стандартным способом. Т.е. каждый сеанс видит количество проданных и количество "заблокированных" билетов в реальном времени. 2 Alexey Sh andrushok - прав. запуск процесса - дорогое удовольствие. Поэтому в системах и используют сервера приложений, которые держат очередь запросов на транзакции от клиентов и пропускают эту очередь через пул соединений. Выигрыш может составить 200-300%. А может и больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 10:20 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторАбсолютно правы. А теперь с другой стороны - блокировка ставится для того, чтобы всех клиентов построить в очередь к ресурсу . Я в своем варианте слегка "расширил" возможности этого подхода позволив клиенту считывать незакомиченные , но согласованные данные построив их в очередь перед семафором. Поэтому "лишний" билетик продать невозможно. А сам ресурс (запись с количеством доступных билетов) блокируется и освобождается стандартным способом. Т.е. каждый сеанс видит количество проданных и количество "заблокированных" билетов в реальном времени. Я так и не понял, зачем вы транзакцией блокируете данные и потом из-за этого используете грязное чтение? Этого я не пойму!!! У вас есть таблица с билетами, на которые идет оформление (если я правильно понял), зачем вам ее блокировать а потом грязно читать? Не пойму я - зачем тут блокировки на уровне транзакций? Вы что, в эту таблицу и так не можете посмотреть, чего там у вас? И кстати, зачем выстраивать в очередь клиентов? Они сами выстроятся - когда количество менять будете в проданных и заблокированных. Мдааааа. Вы все-же словами - не надо скриптов - еще раз пояснили бы алгоритм. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 11:27 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
типа... последний раз попытаюсь объяснить что я имею в виду. Оракл: Запись с количеством билетов обновлена, но коммит еще не сделан. Никто не видит реального количества билетов. Всем доступно только предыдущее значение. Поэтому сказать точно сколько билетов еще можно продать - никто не может. (грязное чтение отсутствует как класс) Т.е. можно так выразиться (перефразировать) невозможно работать в реальном времени. Все клиенты вынуждены вставать в очередь и ждать когда можно будет заблокировать запись и получить актуальное количество доступных билетов. DB2: (режим - грязное чтение) видно - что запись обновлена, видно сколько в билетов на данный момент другие намериваются продать (типа зарезирвировано). Но, однако чтобы получить эти данные, и быть уверенным что пока я их читаю и резервирую некоторое количество билетов, никто их не поменял, перед считываением выставляется семафор, резервируется некоторое количество билетов (добавляется запись в таблицу Locks), затем семафор освобождается. Я начал транзакцию, но горячий ресурс с количеством свободных билетов - не заблокировал. Теперь я могу в любой момент закончить транзакцию, гарантируя что зарезервированные мной билеты имеются, и транзакция завершится удачно. (т.е. очередь к горячему ресурсу отсутствует) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 11:52 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
т.е. я хочу сказать что при таком подходе ситуация в которую попал многоуважаемый hell (пока оформляли билет - оказалось что билетов нет(стихами заговорил))- невозможна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 11:56 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanтипа... последний раз попытаюсь объяснить что я имею в виду. Оракл: Запись с количеством билетов обновлена, но коммит еще не сделан. Никто не видит реального количества билетов. Всем доступно только предыдущее значение. Поэтому сказать точно сколько билетов еще можно продать - никто не может. (грязное чтение отсутствует как класс) Т.е. можно так выразиться (перефразировать) невозможно работать в реальном времени. Все клиенты вынуждены вставать в очередь и ждать когда можно будет заблокировать запись и получить актуальное количество доступных билетов. DB2: (режим - грязное чтение) видно - что запись обновлена, видно сколько в билетов на данный момент другие намериваются продать (типа зарезирвировано). Но, однако чтобы получить эти данные, и быть уверенным что пока я их читаю и резервирую некоторое количество билетов, никто их не поменял, перед считываением выставляется семафор, резервируется некоторое количество билетов (добавляется запись в таблицу Locks), затем семафор освобождается. Я начал транзакцию, но горячий ресурс с количеством свободных билетов - не заблокировал. Теперь я могу в любой момент закончить транзакцию, гарантируя что зарезервированные мной билеты имеются, и транзакция завершится удачно. (т.е. очередь к горячему ресурсу отсутствует) Если Вы намереваетесь использовать понятие резервирования, то отразите его в структуре данных. Вы пытаетесь внушить нам, что механизм транзакций сервера надо использовать для моделирования понятий предметной области. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 11:58 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 Dogen Если вы подразумеваете, что резервирование - это синоним бронирования, или эээ. предварительной продажи, то - ОК! Назовем это не резервированием, а назовем это - блокированием на время проведения транзакции. Впрочем термин можете подобрать сами. Это не изменит сути процесса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 12:04 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2gardenman опять читал 3 раза :) вы предлагаете при бронировании запускать на пару недель транзакцию с блокировкой ? я правильно понял ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 12:27 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Yo!2gardenman опять читал 3 раза :) вы предлагаете при бронировании запускать на пару недель транзакцию с блокировкой ? я правильно понял ? Я больше объяснять не буду. Я лучше жестами покажу @#$!@#$ ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 12:32 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman2 Dogen Если вы подразумеваете, что резервирование - это синоним бронирования, или эээ. предварительной продажи, то - ОК! Назовем это не резервированием, а назовем это - блокированием на время проведения транзакции. Впрочем термин можете подобрать сами. Это не изменит сути процесса. нет-нет я имею в виду отметку о том что место занято - в момент начала оформления билета это укладывается в бизнес-процесс выписки - застолбил место и давай вводить паспортные данные бронирование - это отметка о том что на это место имеется бронь бронь снимают за сутки и за 4 часа до поезда (может и за час, не знаю). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 12:34 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Ну наконец-то я получил тот ответ, который ожидал. Присоединяюсь к остальным: вы пытаетесь методами сервера БД решить задачу, которая должна решаться методами архитектуры системы, причем решаете извращенно как оееееей. По-русски вам объясняю решение: Пишете в отдельную ли таблицу, либо поле таблицы с билетами количество забронированных на оформление билетов. И все. Чтобы узнать, сколько билетов осталось, нетрудно понять, что нужно из Доступного количества отнять Забронированное количество. После того, как билет оформлен, соответственно уменьшаем цифру в Доступном и забронированном количестве. И тоже все. Вообще никаких грязных чтений, блокировок и ничего страшного. Если вы это до сих пор понять не можете, то вашему работодателю нужно вас гнать в шею - извините уж, но это так и есть. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 13:02 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
tygraНу наконец-то я получил тот ответ, который ожидал. Присоединяюсь к остальным: вы пытаетесь методами сервера БД решить задачу, которая должна решаться методами архитектуры системы, причем решаете извращенно как оееееей. По-русски вам объясняю решение: Пишете в отдельную ли таблицу, либо поле таблицы с билетами количество забронированных на оформление билетов. И все. Чтобы узнать, сколько билетов осталось, нетрудно понять, что нужно из Доступного количества отнять Забронированное количество. После того, как билет оформлен, соответственно уменьшаем цифру в Доступном и забронированном количестве. И тоже все. Вообще никаких грязных чтений, блокировок и ничего страшного. Если вы это до сих пор понять не можете, то вашему работодателю нужно вас гнать в шею - извините уж, но это так и есть. -- Tygra's -- И это еще что. Как только появится касса, общающаяся с головной БД методами оффлайновой репликации (ну раз в полчаса, например), начнется кино - транзакции не помогают, ой-ой-ой. В МПС это, как я догадываюсь, решали путем раздачи квот на места в конкретном поезде. Но мы же про крутую современную систему говарим :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 13:14 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 andrushok andrushok LeXa NalBat andrushokНакладные расходы на connection не велики, про крайне мере для Oracle и MsSQL.Вы ошибаетесь. Можете сказать лишь следующее: "накладные расходы на connection не велики, про крайне мере для задач, с которыми я сталкивался на Oracle и MsSQL".Я не ошибаюсь (я так думаю, вообще-то), однако, они _дейсвительно_ не велики. Хотя и зависят от многих факторов, в частности оракл и cgi на одном сервере или нет. Я таки про cgi толкую, на не про весь спектр задач, включаюших оракл. Хотя, полностью согласен, что использовнание долгоиграющей connection может увеличить производительность."Они _дейсвительно_ не велики." Я привел вам ссылку на результат моего теста: время коннекта в 0.019 сек не велико по сравнению со временем выборки в 0.0035 сек? "Я таки про cgi толкую, на не про весь спектр задач, включаюших оракл." Из вашего категоричного утверждения "накладные расходы на connection не велики, про крайне мере для Oracle и MsSQL" непонятно, что вы толкуете исключительно про cgi. :) Даже если это так, то все равно вы не правы, потому что на все задачи веб-программирования ваше утверждение распространить нельзя. Сейчас наш веб-сервер отдает страницу объемом 20-60 Кб, содержащую 5-20 строк из БД, за 0.1-0.3 сек. Если бы мы не использовали persistent connectios, то на показ каждой страницы тратилось бы еще время для подключения к БД, равное 0.02 сек. То есть благодаря постоянным подключениям мы имеем выигрыш в производительности в 7-20%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 19:46 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Уважаемый Леха Налоговый, Мы с Вами об одном и том же толкуем. Вот тольки по разному. 0.019 сек - это много? Помойму нет. То, что мой cgi за время своей жисти переконектится 2-3 раза - проблем не вижу никаких. Пусть даже 10 раз, фигня это все - 0.2 сек. Зато даст возможность другим cgiям жить спокойно. А то, что всяки там выборки идут за 0.0 ... 001 сек, мне как-то фиолетово, все равно потеря впемени на траффике все съедает. Cgi, если их конечно правильно писать, долго жить не должны. Хотя, бывают, конечно исключения. Всяки там отложенные запросы. Такой cgi может и час пахать (на самом деле не cgi а кака-нить апликуха, а другие cgiи тольки ее статус проверяють, пашат она еще, или закончилась уже). Ну дык, это совсем другой случай. По сему этому, Ваши попытки, доказать, что я не прав, странны однако. Опять таки я про _cgi_ говорю, а не про все веб-приложения. На виндах cgi то не очень хорошо чуйствует. Там надоть какий-то DLL (точнее их расширения, не помню). Вот они и живут в памяти, и с IIS общаются как-то. Вот там подход может быть совсем другой. А к словам цепляться, нехорошо. Негигиенично... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 22:04 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushok0.019 сек - это много? Помойму нет.Так ставить вопрос нельзя. Много по сравнению с чем? Много в какой ситуации, для какой задачи? Два кило яблок - это много? Сожрать в одно рыло - да, закрыть на зиму компотов - нет. И отвечать надо не так, а как я вас уже учил :) "Помойму для задач, с которыми я сталкивался, нет." andrushokТо, что мой cgi за время своей жисти переконектится 2-3 раза - проблем не вижу никаких. Пусть даже 10 раз, фигня это все - 0.2 сек.Если мой скрипт переконнекчивался бы 10 раз за время своего выполнения, то количество серверов нам пришлось бы удваивать. :) Для моего начальства - это бабки, а не фигня. :) andrushokпотеря впемени на траффике все съедает.Съедает что? Память, процессорное время? Если клиент (веб-броузер) задерживает апачевского ребенка, медленно читая данные, то при этом апачевский ребенок будет спать, то есть занимать память, но не процессорное время. andrushokПо сему этому, Ваши попытки, доказать, что я не прав, странны однако.Я сказал, что вместо неверного утверждения "накладные расходы на connection не велики, про крайне мере для Oracle и MsSQL", вы можете сказать лишь "накладные расходы на connection не велики, про крайне мере для задач, с которыми я сталкивался на Oracle и MsSQL". Я не нахожу такое уточнение странным хотя бы потому, что лично у меня есть подтверждающий его пример. andrushokОпять таки я про _cgi_ говорю, а не про все веб-приложения.Я полагал, что "cgi-программирование" и "веб-пограммирование" - одно и то же. Объясните пожалуйста разницу. andrushokА к словам цепляться, нехорошо. Негигиенично...О цеплянии к словам vs точности формулировок я как-то рассказал анекдот. :) P.S.: К налоговому ведомству отношения не имею. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 19:26 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 Леха Ватный (если Налоговый не нравится - извините) Я так думаю, разговор заходит в тупик - для Вас 0.019 сек много, для меня нет. Спорить тут уже бессмысленно. Вы можете дать пример Вашего web, где сие критично? Я могу - сюды пожалста . Кстати - для ликбеза - сие произведение программиского искуйства (я не скромен, а?) в основном наваено на ColdFusion - что к CGI технологии не имеет никакого отношения. Хотя cgiи там все-же есть, их время от времени и жаба дергает, и на прямую из HTML и JavaScript для некоторых целей вызывают. Но их там мало, да и чужеродны они там. Я думаю - это web приложение. И _почти_ без CGI. Если постораться, можно найти и _совсем_ без CGI. Ну если Вам так угодно, я могу согласиться, что только, с теми, к какими я сталкивался. Мир велик, и я за все программы не в ответе. Ну шо, мир, или бум дальше пиписками мериться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 20:26 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushokВы можете дать пример Вашего web, где сие критично?price.ru andrushokНу если Вам так угодно, я могу согласиться, что только, с теми, к какими я сталкивался.Иейс! (Как сказал бы мальчик, который "один дома".) Теперь с этим вашим утверждением смог бы поспорить только программист, столкнувшийся с тем же проектом что и вы, и обнарувший, что в этом проекте "расходы на connection не малы по сравнению с другими расходами". :) andrushokНу шо, мир, или бум дальше пиписками мериться?Не будем уподобляться Беклемишеву. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 20:54 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Ну шо, посмотрел я Вашу price. Так, шустро работает. Правда, HTML простой, как сибирский валенок. Ни те фреймов, ни DHTML, ни JavaScript, ни какой жабы конечно (может иде есть, везде не лазил). Конечно, еще с Macа интерестно залесть, как оно там под Camino например пашет, или (упоси Господь) под маковский IE. Вот тольки вопросик, а чой то за скриты таки хитрые либо без расширения, либо с html (?) расширением Код: plaintext 1. 2. Интерестна, а? Кстати, а Вы согластны, что есть некоторые приложения, иде время connection особой роли не играет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 22:51 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushokПравда, HTML простой, как сибирский валенок.Видимо усложнение хтмл-я не является целью нашего вебмастера. :) Лично я с этим согласен. andrushokНи те фреймов, ни DHTML, ни JavaScript, ни какой жабы конечно (может иде есть, везде не лазил).По-моему из этого используется только немного джаваскрипта. andrushokВот тольки вопросик, а чой то за скриты таки хитрые либо без расширенияВроде бы в конфиге апача несложно определить обработчик для расширения или директории. Мы используем мод_перл. andrushokКстати, а Вы согластны, что есть некоторые приложения, иде время connection особой роли не играет?Конечно. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 23:34 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Леха Ватный Видимо усложнение хтмл-я не является целью нашего вебмастера. :) Лично я с этим согласен. Я тоже, не люблю наворотов. Можете радоваться, что вам (Вам и вашему веб мастеру) позволена така роскошь Леха Ватный По-моему из этого используется только немного джаваскрипта. Ну без него воще тяжело. Рас мало, вот и не нашел. Правильной дорогой идете, товарищи... Леха Ватный Вроде бы в конфиге апача несложно определить обработчик для расширения или директории. Мы используем мод_перл. И совсем не "вроде бы". Есть там некий AddHandler который это все отпахивает. Я се про расщирения. Ну и с директориями там усе тип-топ. Вот тольки зачем html у перлового скрипта иметь - непонятно. Наверно, чоб враги не догадались! Я ничого супротив не имею... Хоть xxx ставте, любителей порнухи дразнить что бы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2005, 00:47 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
LeXa NalBatНе будем уподобляться Беклемишеву. :) Билят, везде физтехи? Сорь за оффтоп ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2005, 03:21 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushokВот тольки зачем html у перлового скрипта иметь - непонятно.Вроде бы мы так и не делаем. Это - хтмл с мод-перловыми вставками, это - скрипт. Лох ПозорныйБилят, везде физтехи?Только с разной плотностью. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2005, 13:34 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Да, Леха, еще один мумент. Ваше творение никак не предполагает активного участия юзерей. Может, я что-то и не раскопал, копал не глубоко - сознаюсь. Но совсем не похоже, что есть воще кака-нить транзакция, кады я например, зашел туды. Так, сплошной SELECT. Для меня, как для конечного пользователя - сия база ReadOnly - я там ничего не меняю. Ну а кады кажный юзверь, сволочь така, норовит чо-нить в базе напортить, INSERT с UPDATE всяки шлет - подход может быть совсем другой, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2005, 19:47 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторПишете в отдельную ли таблицу, либо поле таблицы с билетами количество забронированных на оформление билетов. И все. Чтобы узнать, сколько билетов осталось, нетрудно понять, что нужно из Доступного количества отнять Забронированное количество. После того, как билет оформлен, соответственно уменьшаем цифру в Доступном и забронированном количестве. И тоже все. Вообще никаких грязных чтений, блокировок и ничего страшного. А если задачу усложнить. Допустим решается задача складского учета. Списывается товар со склада. Причем при списании нужно узнать учетную (себестоимость) цену товара расчитываемую по методу ФИФО, ЛИФО или средних. При этом возможны правки "задним" числом. Опять же используется дополнительная таблица хранящая остатки в учетных ценах для каждой строчки документа. Ну например для Накладной №5 строчка 3 списывается 5 банок огурцов, из них 3 приходили по 10руб, а 2 по 5 руб. В MSSQL тут без блокировок ни как, так как при правке задним число все может поменяться то есть допустим стать 5 банок по 4 рубля. А как в Oracle? Я так понимаю требуется совершенно другая архитектура. Вопрос задан сугубо из познавательных целей, в Oracle я полный профан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 14:01 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Crip авторПишете в отдельную ли таблицу, либо поле таблицы с билетами количество забронированных на оформление билетов. И все. Чтобы узнать, сколько билетов осталось, нетрудно понять, что нужно из Доступного количества отнять Забронированное количество. После того, как билет оформлен, соответственно уменьшаем цифру в Доступном и забронированном количестве. И тоже все. Вообще никаких грязных чтений, блокировок и ничего страшного. А если задачу усложнить. Допустим решается задача складского учета. Списывается товар со склада. Причем при списании нужно узнать учетную (себестоимость) цену товара расчитываемую по методу ФИФО, ЛИФО или средних. При этом возможны правки "задним" числом. Опять же используется дополнительная таблица хранящая остатки в учетных ценах для каждой строчки документа. Ну например для Накладной №5 строчка 3 списывается 5 банок огурцов, из них 3 приходили по 10руб, а 2 по 5 руб. В MSSQL тут без блокировок ни как, так как при правке задним число все может поменяться то есть допустим стать 5 банок по 4 рубля. А как в Oracle? Я так понимаю требуется совершенно другая архитектура. Вопрос задан сугубо из познавательных целей, в Oracle я полный профан. Какая разница, какая у СУБД архитектура?.. Скорее всего Вам придется озаботиться каскадным пересчетом себестоимостей в документах. Остатки в учетных ценах - это не предмет для продажи, т.к. учетные цены в Вашей модели могут в любой момент измениться. А вот количественные остатки по партиям товара - это да. Кстати, Вы их автоматически рассчитывать будете или дадите возможность выбрать партии товара вручную? Цены на них надо иметь разные, но "ценообразование в онлайне" имхо вещь довольно-таки ненужная. По моему мнению, архитектура такой системы сильно зависит от бизнес-процесса. Если же Вы собираетесь делать тиражируемое решение, то объем работ будет очень большой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 14:09 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторПо моему мнению, архитектура такой системы сильно зависит от бизнес-процесса. Если же Вы собираетесь делать тиражируемое решение, то объем работ будет очень большой Ну это я и сам знаю. В данном случае шла речь только о автоматическом формировании партий, а зачем это бизнесу вопрос не стоял. Просто хотелось услышать как решается вопрос поддержания целостности данных при такой постановке задачи в Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 14:24 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Crip авторПо моему мнению, архитектура такой системы сильно зависит от бизнес-процесса. Если же Вы собираетесь делать тиражируемое решение, то объем работ будет очень большой Ну это я и сам знаю. В данном случае шла речь только о автоматическом формировании партий, а зачем это бизнесу вопрос не стоял. Просто хотелось услышать как решается вопрос поддержания целостности данных при такой постановке задачи в Oracle. У меня возникло такое впечатление, что Вы решили цену банки сделать составной частью первичного ключа партии товара. Если я не прав, то о какой целостности идет речь??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 14:27 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
>А как в Oracle? Я так понимаю требуется совершенно другая архитектура. получить блокируещее чтение в оракле можно через select ... for update ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 14:30 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторУ меня возникло такое впечатление, что Вы решили цену банки сделать составной частью первичного ключа партии товара Хм... Это был всего лишь пример. Первичным ключом партии, если это можно так назвать, в данном случае является ID строки документа прихода... Хотя это тоже упрощенный подход. авторполучить блокируещее чтение в оракле можно через select ... for update То бишь блокировки в Oracle все же есть и при случае их можно применить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 15:07 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushokДа, Леха, еще один мумент. Ваше творение никак не предполагает активного участия юзерей. Может, я что-то и не раскопал, копал не глубоко - сознаюсь. Но совсем не похоже, что есть воще кака-нить транзакция, кады я например, зашел туды. Так, сплошной SELECT. Для меня, как для конечного пользователя - сия база ReadOnly - я там ничего не меняю.Да, у нас транзакций мало-мало. Подавляющая часть запросов - select. andrushokНу а кады кажный юзверь, сволочь така, норовит чо-нить в базе напортить, INSERT с UPDATE всяки шлет - подход может быть совсем другой,Думаю, да. Но может быть и для этой задачи попробовать, как вам советовали, commit или application server. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 15:10 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
>То бишь блокировки в Oracle все же есть и при случае их можно применить? да. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 15:25 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Понятненько. Хотя я думаю, что для моего примера не подойдет. В MSSQL в случае блокировки остальные сессии просто ожидают ее снятия... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 15:43 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
ну тогда не у казывайте nowait и будет он ждать вечно ... но подождать минуту wait 60 имхо правильней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 15:51 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Блин, циску меняли, выпал :)) авторВ MSSQL тут без блокировок ни как, так как при правке задним число все может поменяться то есть допустим стать 5 банок по 4 рубля. А смысл в блокировке? Чтобы никто не смог прочитать накладную, пока вы ее меняете задним числом? Ну так... Это вообще зависит от архитектуры. И от конкретной ситуации. Если к накладным обращаются ежесекундно, а внесли сейчас неправильно, а нужно чтобы сейчас уже было правильно , тогда наверное стоит ставить блокировку. А если накладная была введена месяц назад например, то какой смысл в блокировке - от кого? Все, кто мог, уже накладную "поиспользовали", и ничего не изменится от того, поправите вы в 16.45 или 16.55 с блокировкой или без - прошло уже очень много времени, чтобы думать о таких мелких вещах, как блокировка :)) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 16:44 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2tygra Так изменение одной накладной подразумевает каскадное изменение таблицы остатков, при этом другие пользователи также эту таблицу обновляют... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 17:47 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
ЗЫ: Вообще задача конечно бессмысленная и на практике трудновыполнимая, потому как конкуренция возрастает не по детски. Но что поделать если бизнес так потребовал, а прошибить их медные лбы не получается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 17:48 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Crip2tygra Так изменение одной накладной подразумевает каскадное изменение таблицы остатков, при этом другие пользователи также эту таблицу обновляют... Сколько документов изменять будете, столько раз и текущие остатки пересчитаете. Не вижу никаких логических проблем. Естественно, обновлять надо с блокировкой записей об остатках - ну так select for update вам должно помогать, нет? Вообще можно это на последовательных транзакциях сделать, если делать все быстро то никто и не заметит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 18:01 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2Dogen Все так если закрывать период достаточно часто, а вот если какой-нибудь сумасшедший юзер захочет поменять что-то в начале квартала, то все остальные будут считать ворон... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 18:14 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Это ничего если я вмешаюсь? Обычно я вот так вот (буду в синтаксисе оракла писать) : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. не делаю, делаю проще: Код: plaintext 1. 2. Аналогичная ситуация в DB2. (в DB2 и в Oracle транзакции начинаются неявно, но завершаются всегда явно, - типа промышленные субд все-таки). А вот в MSSQL, Sybase, если явно не сказал BEGIN TRAN, то и COMMIT делать не обязательно, потому как всякая операция там - атомарна. Поэтому можно просто бахнуть: Код: plaintext 1. Несколько хуже обстоят дела у Оракла с курсорами. Я так полагаю держать долго открытый курсор там не рекомендуется. Вообще-то я еще не пробил этот вопрос. Если кто знает, то может скажет, нарвусь ли я на ORA-01555 в том случае если в одной сессии просто открою курсор выберу 1 запись (коммит не делаю), а затем открываю другую сессию, делаю кучу изменений, а затем начну фетчить открытым курсором в первой сессии? На вскидку скажу что для блокировочника обсолютно пофиг как долго будет держаться курсор открытым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 18:30 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanЭто ничего если я вмешаюсь? Обычно я вот так вот (буду в синтаксисе оракла писать) : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. не делаю, делаю проще: Код: plaintext 1. 2. Аналогичная ситуация в DB2. (в DB2 и в Oracle транзакции начинаются неявно, но завершаются всегда явно, - типа промышленные субд все-таки). А вот в MSSQL, Sybase, если явно не сказал BEGIN TRAN, то и COMMIT делать не обязательно, потому как всякая операция там - атомарна. Поэтому можно просто бахнуть: Код: plaintext 1. Я охреневаю и умолкаю Живите в своем мире DIRTY READ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 18:36 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 Леха Commit конечно транзакцию закрывает, это правда. А вот сессию (connection) зачем тады держать, если программа просто считать начинает. Лучше отпустить, пусть другие попользуются. Одно дело, кады все _расчеты_ в БД делаются, совсем другое - когда на стороне... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 22:31 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1546074]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
87ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
156ms |
get tp. blocked users: |
2ms |
| others: | 273ms |
| total: | 572ms |

| 0 / 0 |
