Блог

Как что-то вроде Entity Framework отслеживает изменения в своих данных, когда изменения данных могут происходить из других источников? Например: когда запущен кластер одного и того же приложения asp net core, и если одно приложение обновляет запись, но оно отслеживается в другом экземпляре, и этот экземпляр получает запрос get, не будет ли он отправлять устаревшие данные?

В принципе, как ORM сохраняют ACIDity, если они выполняют отслеживание локальных изменений?

Это помогает думать о контекстах EF и их локальном кэшировании, особенно как о недолговечных. Когда вы читаете объект, следует рассматривать «продолжительность жизни» этого объекта как соответствующую продолжительности жизни DbContext, который его создал. По истечении этого срока службы объект фактически просто считается похожим на любую другую потенциально устаревшую копию данных. Даже в течение этого срока службы они не синхронизируются с базовым источником данных, поэтому суть истины заключается в том, когда вызывается SaveChanges . Кэширование, предоставляемое EF, больше похоже на сценарий: «Я собираюсь загрузить некоторые объекты, и эти объекты ссылаются на другие объекты. По мере того, как код перебирает объекты, когда он натыкается на ссылку на что-то другое, EF проверяет, было ли это что-то еще загружено, и обслуживает это перед отправкой в БД.» Таким образом, в этом смысле долговечный DbContext — это плохо, потому что некоторые из этих кэшированных данных могут быть довольно старыми и устаревшими, и по мере того, как DbContext загружает больше данных, просмотр этих отслеживаемых объектов замедляется, а контекст потребляет больше памяти.

В веб-приложениях область действия DbContext обычно ограничивается одним запросом или короче этого. (Единица работы) Это означает, что изменения в одновременно обрабатываемых запросах не уведомляются об изменениях друг друга, и ни один запрос не видит изменений, внесенных другими источниками в период между тем, как эти контексты запросов загрузили свои данные и подготовились к сохранению. EF может быть проинформирована о том, что нужно проверять на наличие одновременных изменений, обычно это временная метка версии строки, и может блокировать обновление, если эта проверка завершается неудачей. Помимо этого, именно разработчик должен определить, какие действия предпринять. Это часто означает обнаружение ошибки параллелизма и последующую передачу соответствующему обработчику для регистрации деталей и уведомления пользователя. Это может быть сценарий «Первый в wins», когда пользователь получает уведомление о том, что его изменения завершились неудачей, и повторяет попытку; (с предоставленными обновленными данными) Сценарий последнего выигрыша, в котором пользователю предлагается сообщить, что произошли изменения, но он может перезаписать; (и, надеюсь, зарегистрировать событие на случай возникновения споров / вопросов) Или слияние, при котором система проверяет изменения и предоставляет подробную информацию о любых конфликтах и изменениях, чтобы пользователь мог просмотреть и скорректировать / принять / или отменить их обновление.

EF может помочь обнаружить это, но в конечном итоге разработчик должен написать код для того, что с этим делать.

С точки зрения обнаружения одновременных изменений по мере их возникновения, это требует преднамеренного кодирования для выполнения таких действий, как передача изменений между сеансами (публикация / подписка), когда каждый сеанс прослушивает обновления объектов, над которыми он активно работает, и передает изменения объектам по мере их обновления. Обнаружение возможных других изменений в данных из других источников означает, что другой процесс прослушивает обновления БД (помимо изменений, о которых он уже знает, внесенных системой) и отправляет уведомления об этих изменениях во все активные сеансы. Конечно, очень здорово видеть, как это работает в действии, но затраты и сложность, которые это вносит, должны быть оправданы, помимо простого решения проблем параллелизма при сохранении. 🙂