.net ORM에 대해 수천 번 질문했지만, 어떤 ORM이 멀티 스레드 환경에서 작동하기 쉬운지 알고 싶습니다. 광고 방송 또는 무료 모두 환영합니다.멀티 쓰레딩을 더 잘 지원하는 .NET ORM?
현재 Devexpress에서 XPO를 사용하고 있지만 멀티 스레드 응용 프로그램에서 사용하기가 쉽지 않습니다. 하나의 스레드에서 객체를 다른 스레드에서 공유 할 수 없습니다. 다른 스레드에서 사용하려면 키를 사용하여 DB에서 객체를 찾아야합니다. 정말 짜증납니다. DB 객체의 상태를 잠그더라도 DB 객체의 상태를 DB에 유지할 수는 없습니다. 예 : Save() 메서드는 객체를 만드는 스레드가 아닌 다른 스레드에서 호출 할 수 없습니다.
나는 지금 XPO를 시작하고 있습니다. 아마 잘못 사용하고있을 수도 있습니다.
nHibernate은 많은 응용 프로그램에서 사용되고 있으며 그 중 일부는 멀티 스레드입니다.
는 concurrency에 대한 설명서, 특히 섹션10.2을 참조하십시오 - 명확
ISession 안전
하지 스레드가있는 것을 나타냅니다 (그래서 당신이 자신을 관리해야합니다).
당신이 우려하는 한 ORM을 "쉽게 작동하게"만들 수있는 이유를 명확히 해 주실 수 있습니까?
모든 O/RM은 멀티 스레드 응용 프로그램에서 완벽하게 작동합니다. ASP.NET 응용 프로그램에서 SQL 및 Entity Framework에 LINQ를 사용했습니다 (정의 당 멀티 스레드 됨).
다중 스레드 환경에서 O/RM을 사용하는 데 문제가있는 경우 잘못 사용했을 수 있습니다. 예를 들어 대부분의 O/RM 도구에는 LINQ to SQL의 DataContext, Entity Framework의 ObjectContext 및 XPO의 Session과 같은 작업 단위 패턴을 구현하는 형식이 있습니다. 작업 단위 (UOW)는 단일 스레드에 의해 작성되고 제어되어야합니다. 이런 식으로 이런 객체를 사용한다면, 다중 스레드 환경에서 O/RM 도구를 사용하는 데 전혀 문제가 없었습니다.
Entity Framework의 ObjectContext는 스레드로부터 안전하지 않으므로 공유 리소스로 사용하려는 경우 잠금을 사용하여 직접 구현해야 할 수 있습니다.
모든 스레드에 대해 새 개체 컨텍스트를 만들 수 있지만 많은 스레드가 생성/삭제되는 경우 성능 문제가 될 수 있습니다.
또한 각 스레드에 대해 ObjectContext를 사용하면 데이터가 staleness 될 수 있습니다. 아래에 명시된 바와 같이 :
마지막으로 중요한 것은 다중 사용자 동시성 문제입니다. ObjectContext는 처리 될 때까지 해당 엔티티를 영원히 캐시합니다. 다른 사용자가 자신의 ObjectContext에서 동일한 엔티티를 변경하면 첫 번째 ObjectContext의 소유자는 해당 변경 사항을 결코 알 수 없습니다. 이러한 오래된 데이터 문제는 디버깅하기가 어려울 수 있습니다. 실제로 쿼리가 데이터베이스로 이동하여 새로운 데이터로 돌아 오는 것을 볼 수 있기 때문에 ObjectContext는 이미 캐시에있는 오래된 데이터로 덮어 씁니다. 필자가 생각하기에 이것은 오래 지속되는 ObjectContext 인스턴스를 피하는 가장 중요한 이유 일 것이다. ObjectContext는 데이터베이스에서 가장 최근의 데이터를 얻기 위해 코드를 작성했다고 생각하는 경우에도 ObjectContext가 자신보다 더 똑똑하다고 결정하고 대신 이전 엔티티를 돌려 준다. 당신이 스레드를 통해 객체 공유를 시작 할 때마다
당신은 문제가있는 것입니다.ORM 지원에 관계없이 자체 잠금을 구현해야합니다. – Oded
모든 O/RM은 멀티 스레드 환경에서 사용할 수 있습니다. 그러므로 무엇을하려고하는지 설명하십시오. 사용하는 멀티 스레드 환경의 종류는 어떤 방식으로 어떤 방식으로 사용됩니다. – Steven