.NET ORM, который лучше поддерживает многопоточность?

Я знаю, что вопросы о .net ORM задавались тысячи раз, но я хочу знать, с какой ORM легко работать в многопоточной среде. Коммерческие и бесплатные версии приветствуются.

В настоящее время я использую XPO от Devexpress, но мне неудобно использовать его в многопоточном приложении. Объект из одного потока не может использоваться другим потоком, чтобы использовать его в другом потоке, мне нужно найти объект из БД с помощью ключа, это действительно раздражает. Вы не можете сохранить состояние объекта БД в БД, даже если вы заблокируете состояние объекта. например метод Save() не может быть вызван из другого потока, кроме того, который создает объект.

Кстати, я только начинаю работать с XPO, возможно, я использую его неправильно.


multithreading .net orm xpo
person Benny    schedule 04.12.2010    source источник
comment
Всякий раз, когда вы начинаете обмениваться объектами между потоками, у вас будут проблемы. Вам нужно реализовать свою собственную блокировку, независимо от поддержки ORM.   -  person Oded    schedule 04.12.2010
comment
Каждый O/RM можно использовать в многопоточной среде. Поэтому, пожалуйста, объясните, что вы пытаетесь сделать. Какая многопоточная среда используется и каким образом.   -  person Steven    schedule 04.12.2010

Ответы (3)


arrow_upward
1
arrow_downward

nHibernate используется во многих приложениях, некоторые из которых являются многопоточными.

См. документацию по параллельному доступу, в частности раздел 10.2 — там четко сказано, что ISession не потокобезопасен (поэтому вам нужно управлять этим самостоятельно).

Не могли бы вы уточнить, что, по вашему мнению, сделает ORM «легким в работе»?

person Oded    schedule 04.12.2010
comment
Даже с блокировкой объект нельзя использовать совместно в XPO, вы просто не можете вызвать save() из другого потока. - person Benny; 04.12.2010

arrow_upward
1
arrow_downward

Каждый O/RM отлично работает в многопоточном приложении. Я использовал LINQ to SQL и Entity Framework в приложениях ASP.NET (которые являются многопоточными для каждого определения).

Если у вас возникли проблемы с использованием O/RM в многопоточной среде, возможно, вы используете ее неправильно. Например, большинство инструментов O/RM имеют тип, который реализует шаблон единицы работы (например, LINQ to SQL DataContext, Entity Framework ObjectContext и XPO Session). Единица работы предназначена для создания и управления одним потоком. Если вы используете такой объект таким образом, у меня никогда не было проблем с использованием инструмента O/RM в многопоточной среде.

person Steven    schedule 04.12.2010
comment
Можно смело сказать, что каждая O/RM отлично работает в многопоточном приложении. - person cspolton; 04.12.2010
comment
@Spolto: Назовите тот, который этого не делает. - person Steven; 04.12.2010
comment
Entity Framework 4. Если вы достаточно долго используете контекст объекта в отдельном потоке, данные могут легко устареть. - person Robin Orheden; 04.12.2010
comment
NHibernate, как цитирует Одед. Вы правы в том, что они обычно предназначены для использования в однопоточном режиме. - person cspolton; 04.12.2010
comment
Ни в одной из платформ O/RM нет единицы работы, которая является потокобезопасной, но это не означает, что саму инфраструктуру нельзя использовать в многопоточных приложениях. - person Steven; 04.12.2010

arrow_upward
0
arrow_downward

ObjectContext в Entity Framework не является потокобезопасным, поэтому вам, вероятно, придется реализовать свой собственный с блокировкой, если вы хотите использовать его как общий ресурс.

Вы можете создать новый контекст объекта для каждого потока, но если у вас много потоков, порождаемых/умирающих, это может легко стать проблемой производительности.

Кроме того, наличие ObjectContext для каждого потока может привести к устареванию данных. Как указано ниже:

Последнее, но не менее важное, это, конечно, проблема многопользовательского параллелизма. ObjectContext всегда и навсегда кэширует свои сущности, пока не будет удален. Если другой пользователь изменит те же сущности в своем собственном ObjectContext, владелец первого ObjectContext никогда не узнает об этом изменении. Эти проблемы с устаревшими данными могут быть невыносимо трудными для отладки, потому что вы можете фактически наблюдать, как запрос отправляется в базу данных и возвращается с новыми данными, но ObjectContext перезапишет его старыми, устаревшими данными, которые уже находятся в кэше. На мой взгляд, это, пожалуй, самая важная причина избегать долгоживущих экземпляров ObjectContext; даже если вы думаете, что закодировали его для получения самых последних данных из базы данных, ObjectContext решит, что он умнее вас, и вместо этого вернет вам старые сущности.

Контекст объекта Entity Framework в объекте сеанса ASP.NET?

person Robin Orheden    schedule 04.12.2010