Спецов, как погляжу, понаехало - дедлоки увидели, даже трассировок через Environment.CurrentManagedThreadId нету, и столько выводов делается. Вот тут тоже, судя по всему, дедлок. Без лишних Producer-Consumer-ских прикрас :))
//АТАТА!! Тут дедлок - таски не запущены, но у нас все равно дедлок!!! await TestTaskConstructors(); async Task TestTaskConstructors() { var task1 = new Task(() => { Console.WriteLine("Hello world from Task1!"); }); var task2 = new Task(() => { Console.WriteLine("Hello world from Task2!"); }); await Task.WhenAll(task1, task2);
Не надо давать уроков, если нет полного понимания как это работает. Вы только больше хаоса из своей головы вносите.
Давайте разбираться, дабы не ввести добрых людей в заблуждение сим опусом.
Сначала отделим мясо от костей. JPA работает поверх RDBMS леера, и практически все сказанное относится к последнему, и к JPA не имеет никакого отношения. Транзакционность и изолированность данных обеспечивается в первую очередь самой базой данных, а не JPA, которая играет роль лишь обертки ввиде меппера данных и генератора SQL. Теперь:
READ UNCOMMITED — решается с помощью аннотации Version в JPA(об этом как раз и статья)
Это еруйня. Потерянные обновления не возникают в модели RDBMS уже на самом низком уровне READ UNCOMMITED. JPA Version здесь абсолютно ни при чем. К тому же JDBC и в большинство RDBMS по дефолту работают на уровне READ COMMITED.
REPEATABLE READ — при повторном чтении получаются те же данные, что и в начале транзакции. Однако возможна пропажа/добавление рядов от другой транзакции при SELECT… WHERE ..., когда данные удовлетворяют критерию WHERE. Плюс другие транзакции все-же могут изменять прочитанные данные (но не измененные).
SERIALIZABLE — последовательное выполнение транзакций
Симуляция последовательного выполнения с возможностью спонтанного отката ввиду нарушения блокировки. И тем не менее, некоторые вендоры, которые используют схему MVCC, понижают SERIALIZABLE уровень до т.н. "SNAPSHOT" isolation, в котором возможен неприятный феномен типа write-skew.
Теперь вернемся к JPA.
Version была придумана во-первых для того, чтобы можно было отслеживать изменения в Extended Persistence Context, в котором unit-of-work живет дольше одной транзакции, и где Version имплементирует классическую схему MVCC.
два типа блокировок: оптимистичные и пессимистичные. Разница в том, что первые ориентируются на ситуации, в которых множество транзакций пытаются изменить одно поле в одно и тоже время, возникают крайне редко
Разница во-первых в том, что пессимистичные блокировки проверяют соответствие на момент получения блокировки, и как правило для этого исполользуют средства RDBMS (SELECT FOR UPDATE) а оптимистичные — делают все проверки при коммите при помощи сравнения данных или маркеров изменений типа Version. А то, что вы сказали — уже следствие.
В оптимистичных блокировках при коммите в базу данных производится сравнивание значения поля, помеченного как version, на момент получения данных и на данный момент.
Тем не менее поле Version не обязательно. При его отсутствии многие JPA делают полное/частичное сравнение данных полей объектов.
LockModeType.OPTIMISTIC_FORCE_INCREMENT… Вопрос. Зачем? Если после коммита мы хотим еще «поколдовать» над этими же данными, и нам не нужны сторонние транзакции
Вообще не для этого. Это аналог WRITE LOCK для optimistic locking. Гарантирует, что прочитанная Entity не была изменена другой транзакцией до самого коммита, даже если данная транзакция ничего не меняла. Используется для каскадного трекинга изменений, когда поля самой Entity не меняются, но зато меняются ее дочерние entities. При LockModeType.OPTIMISTIC поле Version меняется и проверяется только, если entity была изменена.
Без аттестаций за текущий класс (а осталось буквально два месяца) у вас не будет всех данных для перевода в следующий (в том числе за рубежом в сентябре).
мне думается, что это очень сильное обобщение. И хорошо было бы сузить территориальные границы утверждения - где (в каких странах) это так, а в каких - не так.
Спецов, как погляжу, понаехало - дедлоки увидели, даже трассировок через
Environment.CurrentManagedThreadIdнету, и столько выводов делается.Вот тут тоже, судя по всему, дедлок. Без лишних Producer-Consumer-ских прикрас :))
//АТАТА!! Тут дедлок - таски не запущены, но у нас все равно дедлок!!! await TestTaskConstructors(); async Task TestTaskConstructors() { var task1 = new Task(() => { Console.WriteLine("Hello world from Task1!"); }); var task2 = new Task(() => { Console.WriteLine("Hello world from Task2!"); }); await Task.WhenAll(task1, task2);Не надо давать уроков, если нет полного понимания как это работает. Вы только больше хаоса из своей головы вносите.
Давайте разбираться, дабы не ввести добрых людей в заблуждение сим опусом.
Сначала отделим мясо от костей. JPA работает поверх RDBMS леера, и практически все сказанное относится к последнему, и к JPA не имеет никакого отношения. Транзакционность и изолированность данных обеспечивается в первую очередь самой базой данных, а не JPA, которая играет роль лишь обертки ввиде меппера данных и генератора SQL. Теперь:
Это еруйня. Потерянные обновления не возникают в модели RDBMS уже на самом низком уровне READ UNCOMMITED. JPA Version здесь абсолютно ни при чем. К тому же JDBC и в большинство RDBMS по дефолту работают на уровне READ COMMITED.
REPEATABLE READ — при повторном чтении получаются те же данные, что и в начале транзакции. Однако возможна пропажа/добавление рядов от другой транзакции при SELECT… WHERE ..., когда данные удовлетворяют критерию WHERE. Плюс другие транзакции все-же могут изменять прочитанные данные (но не измененные).
Симуляция последовательного выполнения с возможностью спонтанного отката ввиду нарушения блокировки. И тем не менее, некоторые вендоры, которые используют схему MVCC, понижают SERIALIZABLE уровень до т.н. "SNAPSHOT" isolation, в котором возможен неприятный феномен типа write-skew.
Теперь вернемся к JPA.
Version была придумана во-первых для того, чтобы можно было отслеживать изменения в Extended Persistence Context, в котором unit-of-work живет дольше одной транзакции, и где Version имплементирует классическую схему MVCC.
Разница во-первых в том, что пессимистичные блокировки проверяют соответствие на момент получения блокировки, и как правило для этого исполользуют средства RDBMS (SELECT FOR UPDATE) а оптимистичные — делают все проверки при коммите при помощи сравнения данных или маркеров изменений типа Version. А то, что вы сказали — уже следствие.
Тем не менее поле Version не обязательно. При его отсутствии многие JPA делают полное/частичное сравнение данных полей объектов.
Вообще не для этого. Это аналог WRITE LOCK для optimistic locking. Гарантирует, что прочитанная Entity не была изменена другой транзакцией до самого коммита, даже если данная транзакция ничего не меняла. Используется для каскадного трекинга изменений, когда поля самой Entity не меняются, но зато меняются ее дочерние entities. При LockModeType.OPTIMISTIC поле Version меняется и проверяется только, если entity была изменена.
Нашел свой дом в зелёной зоне, но соседи социальщики с шестью детьми превосходят показатели карты по половине параметров.
Уменьшение углеродного следа? А увеличение его падет на долю коммунистов, они как раз по сжиганию угля впереди планеты всей
мне думается, что это очень сильное обобщение. И хорошо было бы сузить территориальные границы утверждения - где (в каких странах) это так, а в каких - не так.
1) Я начальник — ты дурак, ты начальник — я дурак (рус.)
2) Умный человек нанимает людей умнее себя (eng.)