Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
Дык как раз до этого посмотрел и перечитал доку по Oracle. Но там формулировки ровно такие же, как у Фаулера

в целом-то - глубоко пофик, как спор про ангелов на конце иглы
ни ангелов никто не видел, ни сфеоическую транзакцакцию в вакууме. пока данные не меняются - началось или нет, глубоко пофиг

IMHO на правах бреда, ни на что другое и не притендую

p.s. тест кейс, когда SELECT есть, а начала транзакции (автономной) как бы и нет - привел. UPDATE (не меняющий никаких записей) и SELECT ... FOR UPDATE начинают "active autonomous transaction", а вот SELECT просто - ноль эффекта
16 окт 19, 14:56    [21995573]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
mayton
Member

Откуда: loopback
Сообщений: 42941
Leonid Kudryavtsev, я-бы вместе с SELECT рассмотрел изоляцию. Это способность
видеть или не видеть dirty, фантомы и прочие штуки которые идут еще с эпохи
файловых БД.

Oracle по дефолту всегда включает READ COMMITED. Другие DBMS - не знаю.

Кроме того есть наверное архитектурный gap между уровнями изоляций JDBC
и практическим количеством этих изоляций которые реально поддерживаются
в текущей DBMS.

Грубо говоря они могут не маппится 1:1.

Вообще рассматривать сферический SQL еще можно. В рамках ASNI стандартов.

Но как рассматривать сферическую DBMS и ее режимы изоляции - я не знаю.
Скорее всего - никак.
16 окт 19, 14:57    [21995576]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
PetroNotC Sharp
Господа. Вы зря спорите.

вот лично я, ни сколько не спорю
исключительно ради флуда )))
16 окт 19, 14:59    [21995584]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2481
Leonid Kudryavtsev,
)))
Поддерживаю флуд _осознанный_.
16 окт 19, 15:07    [21995601]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
mayton,

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

в общем, как и весь этот топик изначально
16 окт 19, 15:12    [21995608]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9504
Leonid Kudryavtsev
p.s. тест кейс, когда SELECT есть, а начала транзакции (автономной) как бы и нет - привел.
... только select в курсоре PSQL - вообще ни разу не DML и в этом случае надо читать другие разделы документации.
16 окт 19, 15:52    [21995669]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
mayton
я-бы .... рассмотрел изоляцию. Это способность видеть или не видеть....

Грубо говоря они могут не маппится 1:1


Говорю на бытовом языке, за точностью терминов не гонюсь. Мне кажется, есть два разных механизма СУБД

1. обеспечение версионности = "изоляция"
2. обеспечение целостности при записи

Теоретически "транзакция" это и то и другое ("и можно без хлеба" ( C ), желательно в режиме serialized), практически - две разных механизма, которые не всегда маппятся 1:1

Когда есть UPDATE/DELETE/INSERT мы транзакцию всегда можем "пощупать" т.к. работа механизма N2 вполне себе видна

Если же изменений нет - то транзакция становится чисто призрачным теоретическим термином. Есть она, нет ее.... есть ли ангелы, нет ангелов... сколько их может уместиться на кончике иглы?

В том же самом Oracle, "конец транзакции" в виде SCN /system change number/ есть, а вот есть ли что-то реальное (что можно посмотреть, пощупать) для самой "транзакции" или для "начала транзакции" - я не знаю. С ходу не помню.

Было бы удобно считать, что COMMIT/ROLLBACK == конец одной транзакции == начало другой, но вроде доки и теоретики явно разделяют "конец" и "начало". Поэтому после прочтения док, остается какая-то душевная неопределенность, что тогда должно существовать между-транзакционное пространство.... которое, конечно, никто не видел.... но должны же где-то жить зеленые человечки?

IMHO на правах бреда
16 окт 19, 16:02    [21995683]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
Продолжим бредить дальше. Чисто теоретически.

Нашел такое определения в И-нет
Транзакция (или логическая единица работы) – неделимая с точки зрения воздействия на базу данных последовательность операторов манипулирования данными (чтения, удаления, вставки, модификации) такая, что либо результаты всех операторов, входящих в транзакцию, отображаются в БД, либо воздействие всех этих операторов полностью отсутствует.


Т.е. если воздействия нет, то как бы и термин "транзакция" не применим (и соответственно "начало транзакции")

Как квантовая запутанность.

SELECT запутан с последующими UPDATE'ами. Нет update-ов, нет транзакции, select ничего и не начинает. А вот если... на растоянии 100500 световых лет строк кода, внезапно оказался UPDATE, то "запутанный SELECT" транзакцию уже давно и начал.

Такая вот аналогия :=) на правах бреда
16 окт 19, 16:03    [21995685]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2481
Leonid Kudryavtsev
теоретики явно разделяют "конец" и "начало".
+активная, вложенная, автономная)) распеределенная.
В хибере упрощаем. Транзакция на запрос (вызов метода begin) и остальное за скобками темы.
16 окт 19, 16:08    [21995691]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
mayton
Member

Откуда: loopback
Сообщений: 42941
Leonid Kudryavtsev
mayton
я-бы .... рассмотрел изоляцию. Это способность видеть или не видеть....

Грубо говоря они могут не маппится 1:1


Говорю на бытовом языке, за точностью терминов не гонюсь. Мне кажется, есть два разных механизма СУБД

1. обеспечение версионности = "изоляция"
2. обеспечение целостности при записи

Теоретически "транзакция" это и то и другое ("и можно без хлеба" ( C ), желательно в режиме serialized), практически - две разных механизма, которые не всегда маппятся 1:1

Когда есть UPDATE/DELETE/INSERT мы транзакцию всегда можем "пощупать" т.к. работа механизма N2 вполне себе видна

По SELECT

Приведу практический пример. Вы написали микро-сервис который возвращает инфу по клиенту.
Двумя методами. getBrief(clientId), getFull(clientId). Грубо говоря смотрим в виджет который показывает
краткую сводку. А потом кликаем мышкой и видим детализацию. Паттерн норм? Вполне себе норм.
Продкутовый кейс. Такое часто бывает.

Это две операции select. Но между этими операциями база могла изменятся. И клиент мог
менять какие-то свойства. Ну... по крайней мере бизнес говорит что такое вполне себе возможно.
Чего-ж нет то?

Вот и вопрос следующий. Эти два селекта мы рассматриваем в изоляции от изменений БД? Тогда мы должны
соотв зафиксировать режим транзакций и получить согласованный снимок.

Или мы просто делаем 2 независимых селекта и получаем теоретически разные сеты атрибутов клиента.
16 окт 19, 16:14    [21995695]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2481
mayton
Это две операции select. Но между этими операциями база могла изменятся.
так же как и посты на sql.ru.
Ничего страшного. Если учитывать в коде.
Это асинхронность, в принципе.
С ней сложнее писать как и с микросервисами.
16 окт 19, 16:21    [21995705]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
mayton
Тогда мы должны соотв зафиксировать режим транзакций и получить согласованный снимок.

нифига режимы транзакций по памяти не помню
какой режим Вы предлагаете установить "на практике" ("практический пример" ( C )) ?

интересный кейс, т.к. мне кажется, что попытка перевести его в "оптимистик блокировку" (тема топика) может оказаться не такой уж и простой
16 окт 19, 16:24    [21995708]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8001
mayton
Вы написали микро-сервис который возвращает инфу по клиенту.
Двумя методами. getBrief(clientId), getFull(clientId). Грубо говоря смотрим в виджет который показывает
краткую сводку. А потом кликаем мышкой и видим детализацию. Паттерн норм? Вполне себе норм.
....
и получить согласованный снимок.

Нифига не норм. Как минимум метода "refresh" не хватает )))

получаем статическую фигню, которая всегда возврашает старые данные на момент первого логина юзера

данные может и согласованные, но ... "такая фигня получается" ( C )
16 окт 19, 16:29    [21995712]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2481
Leonid Kudryavtsev,
Этот юзкейс есть в любой системе в принципе.
orm.ПроверитьНаДолги(Имя
orm.ВыдатьКредит(Имя
Между первым и вторым всегда может ситуация измениться.
Это риски и не надо тут блокировать.
16 окт 19, 16:34    [21995717]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
mayton
Member

Откуда: loopback
Сообщений: 42941
Leonid Kudryavtsev
mayton
Вы написали микро-сервис который возвращает инфу по клиенту.
Двумя методами. getBrief(clientId), getFull(clientId). Грубо говоря смотрим в виджет который показывает
краткую сводку. А потом кликаем мышкой и видим детализацию. Паттерн норм? Вполне себе норм.
....
и получить согласованный снимок.

Нифига не норм. Как минимум метода "refresh" не хватает )))

получаем статическую фигню, которая всегда возврашает старые данные на момент первого логина юзера

данные может и согласованные, но ... "такая фигня получается" ( C )

Я вас умоляю. Никто дополнительную кнопку с Refresh не будет делать. Это и по дизайну и по нагрузке
- ненужная фигня.

Просто я подчеркиваю что SELECT может быть "не так прост...."
16 окт 19, 16:35    [21995720]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
mayton
Member

Откуда: loopback
Сообщений: 42941
PetroNotC Sharp
Leonid Kudryavtsev,
Этот юзкейс есть в любой системе в принципе.
orm.ПроверитьНаДолги(Имя
orm.ВыдатьКредит(Имя
Между первым и вторым всегда может ситуация измениться.
Это риски и не надо тут блокировать.

Боже упаси. Я и не предлагаю блокировать.

Нормальный SELECT (как в Оракле) вообще никогда и ничего не блокирует.
16 окт 19, 16:36    [21995722]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
questioner
Member

Откуда:
Сообщений: 1865
PetroNotC Sharp
questioner,
Вот ты на форуме вроде никому не отвечаешь, не помогаешь.
Пришел с вопросом и хамишь, слова матерные употребляешь.
Прогресса в обучении нет. Свой пост про DI не помним.
То что ТС спрашивает и не огрызается ты не согласен.
Может тебя плохо воспитывали? Или маньяк какой одичавший.



Может ты просто своё внимание переключишь на кого-то другого? Твой бред читать смысла нет - всё мимо.

С воспитанием проблемы у тебя
16 окт 19, 16:44    [21995730]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
questioner
Member

Откуда:
Сообщений: 1865
пришло осознание, что в хибере просто оптимистическая блокировка, а у Фаулера оптимистическая автономная блокировка.

В хибере она идёт в рамках одной ДБ транзакции, а у Фаулера одна бизнесс транзакция, а БД-шных сколько хочешь
16 окт 19, 16:52    [21995741]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2481
mayton
Просто я подчеркиваю что SELECT может быть "не так прост...."
да. Он не прост.
Тут мы флудим. То усложняем, то пытаемся упростить до мыслей книжки)
16 окт 19, 16:54    [21995744]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
questioner
Member

Откуда:
Сообщений: 1865
questioner
пришло осознание, что в хибере просто оптимистическая блокировка, а у Фаулера оптимистическая автономная блокировка.

В хибере она идёт в рамках одной ДБ транзакции, а у Фаулера одна бизнесс транзакция, а БД-шных сколько хочешь


Хотя нет....

https://docs.jboss.org/hibernate/orm/6.0/userguide/html_single/Hibernate_User_Guide.html#locking-optimistic
When your application uses long transactions or conversations that span several database transactions, you can store versioning data so that if the same entity is updated by two conversations, the last to commit changes is informed of the conflict, and does not override the other conversation’s work.
16 окт 19, 16:55    [21995746]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
mayton
Member

Откуда: loopback
Сообщений: 42941
Я вообще не понимаю Фаулера здесь. Может его перенести в Программирование или в Проектирование БД

В форуме Java имеет смысол посмотреть с ракурса JDBC/JPA и через призму этих пром-стандартов.
16 окт 19, 16:56    [21995748]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2481
questioner
пришло осознание,
смотрим:
questioner
В хибере она идёт в рамках одной ДБ транзакции

Если расшифруешь "она" тогда посмотрим на твое сознание.
16 окт 19, 16:58    [21995749]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2481
questioner
Хотя нет....
блин)))))
16 окт 19, 16:59    [21995752]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2481
mayton
Я вообще не понимаю Фаулера здесь. Может его перенести в Программирование или в Проектирование БД

В форуме Java имеет смысол посмотреть с ракурса JDBC/JPA и через призму этих пром-стандартов.
ТС не поймет тебя).
Но я с тобой согласен.
16 окт 19, 17:00    [21995755]     Ответить | Цитировать Сообщить модератору
 Re: Фаулер. Оптимистическая блокировка в рамках бизнес-транзакции охватывающей несколько систе  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9504
Leonid Kudryavtsev
Если же изменений нет
... дальше можно не теоретизировать, поскольку БД только для чтения - крайне узкий сегмент.
16 окт 19, 17:22    [21995775]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Java Ответить