Comments 11
А чем вам не угодил стандартный механизм пессимистичных блокировок?
>Тут встаёт вопрос, что за лажу мы только что записали в базу данных?
>Здесь нам и помогут транзакции.
Вы не отразили одну важную тему. Смотрите — у вас есть клиент, он достает и хранит состояние базы на некоторый момент, чтобы показывать его пользователю. Пользователь — это человек, по сравнению с компьютером он тормоз. Он посмотрел на данные, сходил пообедать, вернулся, вздремнул, и нажал кнопку «Обновить все нафиг». И да, он смотрел на давно устаревшие данные, кто бы сомневался. Но дело не в этом.
Вы хотите сказать, что между select (перед показом формы человеку) и update (по нажатию кнопки) у вас все время длилась одна и таже транзакция, которая удерживала блокировку? Часа так три-четыре?
И constraints, кстати не спасают от потери изменений. А это намного более частый случай, чем изменения иерархии, например.
>Здесь нам и помогут транзакции.
Вы не отразили одну важную тему. Смотрите — у вас есть клиент, он достает и хранит состояние базы на некоторый момент, чтобы показывать его пользователю. Пользователь — это человек, по сравнению с компьютером он тормоз. Он посмотрел на данные, сходил пообедать, вернулся, вздремнул, и нажал кнопку «Обновить все нафиг». И да, он смотрел на давно устаревшие данные, кто бы сомневался. Но дело не в этом.
Вы хотите сказать, что между select (перед показом формы человеку) и update (по нажатию кнопки) у вас все время длилась одна и таже транзакция, которая удерживала блокировку? Часа так три-четыре?
И constraints, кстати не спасают от потери изменений. А это намного более частый случай, чем изменения иерархии, например.
Он посмотрел на данные, сходил пообедать, вернулся, вздремнул, и нажал кнопку «Обновить все нафиг». И да, он смотрел на давно устаревшие данные, кто бы сомневался.
Это несколько другая история, нужно целую отдельную статью писать про кондишионал хттп реквесты, е-таги, оптимистичные локи.
Вы хотите сказать, что между select (перед показом формы человеку) и update (по нажатию кнопки) у вас все время длилась одна и таже транзакция, которая удерживала блокировку? Часа так три-четыре?
Ничего подобного я не хочу сказать, в тексте границы транзакции чётко обозначены — начинается при входе в безнес-метод, завершается по выходу из него
И constraints, кстати не спасают от потери изменений. А это намного более частый случай, чем изменения иерархии, например.
Кстати здесь есть варианты. Например, мы можем хранить историю изменений, с помощью ссылочной целостности и констрейнтов мы сумеем гарантировать линейность этой истории. Изменения не потеряются.
Я согласен, это другая история, и у вас правда в примере одна транзакция. Я собственно к тому, что неактуальные данные у клиента — это совершенно нормально, клиент это зачастую человек, и он может долго над данными думать. И тут JPA и его кеши в общем-то не при чем совершенно, это будет так на любой технологии, даже без кеша между вашим select и последующим update данные в базе могут измениться. Т.е. хотите что-то с этим сделать — либо select for update (и не держите транзакцию часами), либо…
Ну в общем это не о том, что у вас что-то неправильно, а скорее небольшое дополнение.
Ну в общем это не о том, что у вас что-то неправильно, а скорее небольшое дополнение.
И constraints, кстати не спасают от потери изменений. А это намного более частый случай, чем изменения иерархии, например.
версионность
Если честно, то ожидал в статье увидеть что-то хоть чуть-чуть близкое к тому как с JPA это все делать, а на деле кричащий заголовок, 2 примитивных примера и очевидные факты для тех кто чуть-чуть познакомился с СУБД.
Ни о каком JPA толком ничего нет.
Продолжение-то хоть намечается?
Ни о каком JPA толком ничего нет.
Продолжение-то хоть намечается?
Sign up to leave a comment.
Как понять и подружиться с транзакциями и JPA