LINQ to SQL을 사용하여 SQL 서버에 연결된 ASP.NET 응용 프로그램이 있습니다. 정적 클래스가있는 곳에서는 확실히 응용 프로그램 수준에서 작동합니다. 어디에서이 정적 클래스에 DataContext의 정적 객체를 생성했는지. 이것을 제외하고 응용 프로그램에서 데이터 컨텍스트 개체를 만들지 않았습니다. 어디로 나는이 정적 데이터 컨텍스트 개체를 각 데이터베이스 조작에 사용하고 있습니다.asp.net 가능한 SQL DataContext 정적 LINQ 트랜잭션을 유지 관리합니까?
이렇게하면 로그인 된 각 사용자에 대해 스레드가 트랜잭션을 안전하게 유지 관리 할 수 있습니까?
참고 : 다음과 같은 조언은 다음과 같은 작업 패턴의 단위를 구현하는 모든 O/RM 도구에 대한 보유 엔티티 프레임 워크의 ObjectContext, DbContext, NHibernate에의 Session 및 LINQ SQL의 DataContext에가.
LINQ to SQL DataContext는 스레드로부터 안전하지 않습니다. 웹 요청 당 최소한 하나의 컨텍스트를 만들어야합니다. 동일한 스레드를 여러 스레드에 걸쳐 재사용한다는 것은 하나의 스레드가 SubmitChanges을 호출 할 수 있으며 다른 스레드는 여전히 새로운 개체를 삽입하고 있음을 의미합니다. 운이 좋다면 DataContext은 변경 사항을 유지할 수 없기 때문에 예외를 throw합니다. 운이 좋지 않다면 DataContext이 성공하고 단일 요청의 애트리뷰트가 깨져 데이터베이스에 일관성없는 데이터가 발생할 수 있습니다. 다른 말로하면 : 당신은 똥으로 가득한 데이터베이스를 갖게 될 것입니다!
그 외에도 DataContext은 모든 개체를 캐시에 유지하므로 응용 프로그램의 메모리 사용량이 계속 증가하여 OutOfMemoryException (OOM)이 될 수 있습니다. OOM을 얻지 못할 경우에도 캐시의 개체가 오래 보관되지 않으며 특히 다른 응용 프로그램이나 프로세스가 데이터베이스를 업데이트하는 경우 엔티티가 이미 메모리에있을 때 이러한 변경 사항을 볼 수 없습니다. 마지막으로주의해야 할 점은 DataContext에서 변경 한 내용을 롤백 할 수있는 방법이 없기 때문에 (한 지점에서) DataContext을 무효화했을 때 (오류로 인해) 복원 할 수있는 방법이 없다는 것입니다 (완전히 새로운 DataContext). 이 경우 AppDomain이 파멸합니다.
슈퍼 좋아요 : "당신은 데이터베이스가 가득 똥!" :) –
단일 DataContext 개체를 사용하려는 결정이 최적이 아닙니다. 필요할 때마다 생성하십시오 (트랜잭션). http://www.west-wind.com/weblog/posts/246222.aspx
모든 업데이트하시기 바랍니다 –