Сообщение Re[4]: [FireBird] deadlock; update conflicts with concurrent от 17.02.2016 9:33
Изменено 17.02.2016 9:33 sushko
Здравствуйте, LuciferNovoros, Вы писали:
S>>Так не бывает. Если пользователь A открыл товар для редактирования, надо сделать как-то так, чтобы пользователь B не смог его открыть для редактирования, т.к. заблокировать запись в транзакции. А если после этого A пойдет пить кофе, не закрыв окно редактирования товара, то транзакция короткой не получится.
LN>FB — версионник. И клиент В всегда получит некую версию записи, с которой будет работать.
Нет, не получит, т.к. клиент B хочет изменить эту запись, а не просто ее прочитать. Блокировка, кот. поставил А, не даст ему этого сделать, и это правильно.
LN>Другой вопрос, что запись может измениться, породив новую версию. И тогда клиент В получит отлуп. Если тебяч такое поведение не устраивает, то выставляй некий признак, что запись заблокирована другим пользователем. И давай отлуп клиенту сразу.
Не получится, т.к. если этот признак выставлять и потом снимать в рамках транзакции клиента А, то клиент В не увидит этого признака, т.к. транзакция клиента А на момент начала транзакции клиента В не завершилась. Если же этот признак выставлять до начала транзакции клиента А (напр. отдельной транзакцией от имени А), то есть вероятность того, что посреди "главной" транзакции клиента А рубанется электричество и признак останется установленным навсегда.
S>>Так не бывает. Если пользователь A открыл товар для редактирования, надо сделать как-то так, чтобы пользователь B не смог его открыть для редактирования, т.к. заблокировать запись в транзакции. А если после этого A пойдет пить кофе, не закрыв окно редактирования товара, то транзакция короткой не получится.
LN>FB — версионник. И клиент В всегда получит некую версию записи, с которой будет работать.
Нет, не получит, т.к. клиент B хочет изменить эту запись, а не просто ее прочитать. Блокировка, кот. поставил А, не даст ему этого сделать, и это правильно.
LN>Другой вопрос, что запись может измениться, породив новую версию. И тогда клиент В получит отлуп. Если тебяч такое поведение не устраивает, то выставляй некий признак, что запись заблокирована другим пользователем. И давай отлуп клиенту сразу.
Не получится, т.к. если этот признак выставлять и потом снимать в рамках транзакции клиента А, то клиент В не увидит этого признака, т.к. транзакция клиента А на момент начала транзакции клиента В не завершилась. Если же этот признак выставлять до начала транзакции клиента А (напр. отдельной транзакцией от имени А), то есть вероятность того, что посреди "главной" транзакции клиента А рубанется электричество и признак останется установленным навсегда.
Re[4]: [FireBird] deadlock; update conflicts with concurrent
Здравствуйте, LuciferNovoros, Вы писали:
S>>Так не бывает. Если пользователь A открыл товар для редактирования, надо сделать как-то так, чтобы пользователь B не смог его открыть для редактирования, т.к. заблокировать запись в транзакции. А если после этого A пойдет пить кофе, не закрыв окно редактирования товара, то транзакция короткой не получится.
LN>FB — версионник. И клиент В всегда получит некую версию записи, с которой будет работать.
Нет, не получит, т.к. клиент B хочет изменить эту запись, а не просто ее прочитать. Блокировка, кот. поставил А, не даст ему ее менять, и это правильно.
LN>Другой вопрос, что запись может измениться, породив новую версию. И тогда клиент В получит отлуп. Если тебяч такое поведение не устраивает, то выставляй некий признак, что запись заблокирована другим пользователем. И давай отлуп клиенту сразу.
Не получится, т.к. если этот признак выставлять и потом снимать в рамках транзакции клиента А, то клиент В не увидит этого признака, т.к. транзакция клиента А на момент начала транзакции клиента В не завершилась. Если же этот признак выставлять до начала транзакции клиента А (напр. отдельной транзакцией от имени А), то есть вероятность того, что посреди "главной" транзакции клиента А рубанется электричество и признак останется установленным навсегда.
S>>Так не бывает. Если пользователь A открыл товар для редактирования, надо сделать как-то так, чтобы пользователь B не смог его открыть для редактирования, т.к. заблокировать запись в транзакции. А если после этого A пойдет пить кофе, не закрыв окно редактирования товара, то транзакция короткой не получится.
LN>FB — версионник. И клиент В всегда получит некую версию записи, с которой будет работать.
Нет, не получит, т.к. клиент B хочет изменить эту запись, а не просто ее прочитать. Блокировка, кот. поставил А, не даст ему ее менять, и это правильно.
LN>Другой вопрос, что запись может измениться, породив новую версию. И тогда клиент В получит отлуп. Если тебяч такое поведение не устраивает, то выставляй некий признак, что запись заблокирована другим пользователем. И давай отлуп клиенту сразу.
Не получится, т.к. если этот признак выставлять и потом снимать в рамках транзакции клиента А, то клиент В не увидит этого признака, т.к. транзакция клиента А на момент начала транзакции клиента В не завершилась. Если же этот признак выставлять до начала транзакции клиента А (напр. отдельной транзакцией от имени А), то есть вероятность того, что посреди "главной" транзакции клиента А рубанется электричество и признак останется установленным навсегда.