MVCC это тот же оптимистик лок (и не факт что блокировки не используются совместно, в SQL Server есть и то и другое). CRDT это больше про eventual consistency и распределенные системы, мол данные записанные в разные реплики сойдутся. Каким-то подходом могут быть например акторы, но они фактически делают доступ к ячейке последовательным, что эквивалентно локу, но сделано за нас. Раньше в EF вообще нельзя было нормально заретраить, счас вроде как можно, но нет желания связываться, 100% они где-то косякнули)
В общем задача решается одинаковая: предсказуемая работа с конкурентным изменением одной области памяти. MVCC это не лок, это версионирование данных. CRDT не обязательно eventual consistency, и уж точно не обязательно распределённые системы. Это больше про математические алгоритмы, как свести результат concurrent вычислений гарантированно без конфликтов (например из многих потоков на одной машине). Акторы это обычная очередь, да очередь это тоже стратегия борьбы с конкурентными изменениями.
Э не, при Optimistic Concurrency в худшем случае не ретрай, а merge conflict - что далеко не всегда тривиальная задача на стороне UI - не показывать же пользователю diff. Azure DevOps не заморачивается: можно написать простыню в тикете, а при нажатии на Save получить: "Извиняй, кто-то тикет уже поменял. Обнови все и заново отредактируй." UX, который мы заслужили.
Интересно бы еще сравнить просто AOT и R2R. Если функция относительно долгоиграющая с большим числом циклов, то оптимизация JIT'а может перекрыть потери на (до/пере)компиляцию и загрузку бОльших бинарей в память. Спрашивал у ребят из команды .НЕТ, не хотят ли они сделать возможность сохранять результат работы JIT+PGO, чтоб можно было это использовать на следующих запусках. Ибо для функций и контейнеров было бы самое оно. Но увы, они это обсуждали, но решили не заморачиваться. =(
Один минус у concurrency token'ов в EF - они работают всегда. Нет возможности при SaveChanges сказать: "Вот эти энтити в этот раз на конкурентный доступ не проверяй."
Спасибо за анализ! У меня возник такой вопрос: На моем SafePal кошельке хранится USDT и у меня есть seed фраза. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). Может подскажете, как отправить их на Binance?
Я человек простой, вижу выпуск ставлю лайк
MVCC это тот же оптимистик лок (и не факт что блокировки не используются совместно, в SQL Server есть и то и другое). CRDT это больше про eventual consistency и распределенные системы, мол данные записанные в разные реплики сойдутся. Каким-то подходом могут быть например акторы, но они фактически делают доступ к ячейке последовательным, что эквивалентно локу, но сделано за нас. Раньше в EF вообще нельзя было нормально заретраить, счас вроде как можно, но нет желания связываться, 100% они где-то косякнули)
В общем задача решается одинаковая: предсказуемая работа с конкурентным изменением одной области памяти.
MVCC это не лок, это версионирование данных.
CRDT не обязательно eventual consistency, и уж точно не обязательно распределённые системы. Это больше про математические алгоритмы, как свести результат concurrent вычислений гарантированно без конфликтов (например из многих потоков на одной машине).
Акторы это обычная очередь, да очередь это тоже стратегия борьбы с конкурентными изменениями.
Э не, при Optimistic Concurrency в худшем случае не ретрай, а merge conflict - что далеко не всегда тривиальная задача на стороне UI - не показывать же пользователю diff. Azure DevOps не заморачивается: можно написать простыню в тикете, а при нажатии на Save получить: "Извиняй, кто-то тикет уже поменял. Обнови все и заново отредактируй." UX, который мы заслужили.
В худшем, да, merge conflict.
Интересно бы еще сравнить просто AOT и R2R. Если функция относительно долгоиграющая с большим числом циклов, то оптимизация JIT'а может перекрыть потери на (до/пере)компиляцию и загрузку бОльших бинарей в память.
Спрашивал у ребят из команды .НЕТ, не хотят ли они сделать возможность сохранять результат работы JIT+PGO, чтоб можно было это использовать на следующих запусках. Ибо для функций и контейнеров было бы самое оно. Но увы, они это обсуждали, но решили не заморачиваться. =(
AOT гораздо быстрее стартует чем R2R. Ну а то что он проигрывает прогретому JIT'у и так видно. Поэтому особого смысла сравнивать нет.
Один минус у concurrency token'ов в EF - они работают всегда. Нет возможности при SaveChanges сказать: "Вот эти энтити в этот раз на конкурентный доступ не проверяй."
Интересное требование. Надо покопаться в интерсепторах, может можно что-то через них настроить.
Вроде же есть pgo?
Да, есть.
Спасибо за анализ! У меня возник такой вопрос: На моем SafePal кошельке хранится USDT и у меня есть seed фраза. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). Может подскажете, как отправить их на Binance?