Стоимость производительности создания ObjectContext в каждом методе в Платформе Объекта v1
Я думаю, что разорванные страницы не проблема. Насколько я знаю, на всех дисках достаточно энергии для завершения записи текущего сектора в случае сбоя питания.
Проблема в том, что все лгут.
По крайней мере, когда дело доходит до базы данных, зная, когда транзакция была зафиксирована на диске, все лгут. База данных выдает команду fsync, и операционная система возвращает данные только тогда, когда все ожидающие записи были зафиксированы на диске, верно? Возможно, нет. Распространено, особенно с картами RAID и / или дисками SATA, когда вашей программе сообщают, что все зафиксировано (то есть возвращается fsync), и все же на диске еще нет данных.
Вы можете попробовать использовать дисковый чек Брэда , чтобы выяснить, сможет ли платформа, которую вы собираетесь использовать для своей базы данных, выжить, потянув за вилку без потери данных. Суть: в случае сбоя Diskchecker платформа не безопасна для работы с базой данных. Базы данных с ACID основаны на знании того, когда транзакция была подтверждена для резервного хранилища, а когда нет. Это верно, независимо от того, использует ли база данных вход в систему с опережением записи (и если база данных возвращается к пользователю, не выполнив fsync, транзакции могут быть потеряны в случае сбоя, поэтому не следует утверждать, что она обеспечивает семантику ACID. ).
В списке рассылки Postgresql обсуждается долговечность . Он начинает говорить о твердотельных накопителях, но затем попадает в диски SATA, SCSI и файловые системы. Вы можете быть удивлены, узнав, насколько ваши данные могут быть потеряны. Это хорошая тема для тех, кто нуждается в долговечности, а не только для тех, кто использует Postgresql.
2 ответа
Является ли основная модель маленькой или большой, простой или сложной? Стоимость инициализации и использования нового объектного контекста растет вместе с размером и сложностью модели. Если у вас есть несколько сущностей, им можно пренебречь. Если у вас есть сотни объектов, это может быть значительным.
См .:
http://oakleafblog.blogspot.com/2008/08/entity-framework-instantiation-times.html
и
http://blogs.msdn.com/adonet/archive/2008/06/20/how-to-use-a-t4-template-for-view-generation.aspx
The cost of creating the context is very low. However, using a new context means that you don't have any cached queries from previous contexts. You can work around this to some degree with view generation or CompiledQuery. See also Performance Considerations for Entity Framework Applications
On the other hand, keeping a context around for a long time means you are tracking increasing amounts of state information, which has a performance cost of its own.
In my opinion, however, the most significant cost of a context is code complication. Using multiple contexts tends to lead to confusing code. So I try to use one context per group of related operations, e.g. handling a single HTTP request.