StructureMap documentation on life cycle에서 하나의 범위 지정 옵션이 HttpSession이고 "HttpContext.Session 컬렉션의 인스턴스를 캐시합니다.주의해서 사용하십시오."라는 내용이 있습니다.SessionMap은 세션에 주입 할 때주의해야합니다 - 이유는 무엇입니까?
나는 무엇에주의해야할지 모르지만 내 Google-fu는 실패하고 있습니다.
우리가 갖고있는 유스 케이스는 우리가 캐시하고 싶어하는 값 비싼 웹 서비스 호출이 있다는 것입니다. 일부는 상태 비 저장이지만 일부는 특정 사용자에게 묶여 있습니다.
우리가 세션 범위에 삽입하면 우리는 언제 나쁠 것입니까? 우리가 지켜야 할 것은 무엇입니까?
I (예 : SQL의 DataContext, 엔티티 프레임 워크의 ObjectContext 또는 DbContext 또는 NHibernate에의 ISession에 LINQ로) 작업 객체의 단위를 캐싱, 극단적 인 예를 사용하여이 가진 문제를 설명 할 것이다 :
메모리 풋 프린트
단위 작업 단위는 대개 많은 양의 객체를 보유합니다. 세션 객체를 HttpSession에두면 세션이 존재하는 한 오래 유지되고 캐시에있는 모든 객체와 함께 유지됩니다. 사용자가 20 분 후에 돌아 오더라도 응용 프로그램에이 메모리 압력이 있습니다. 이것은 메모리 부족 예외를 초래할 수 있습니다 (상당한 부하가 걸릴 수 있습니다).
데이터는 데이터베이스에서로드 된 모든 개체, 데이터가 오히려 빨리 부패하게 작업 객체 캐시의 단위 이후
오래된된다. 다른 사용자가 데이터를 변경하면 기본적으로 캐시 된 데이터가 새로 고쳐지지 않으며 한 사용자에게는 일부 데이터가 표시되지만 다른 사용자에게는 다른 데이터가 표시되는 이상한 동작이 발생할 수 있습니다. 세션의 수명 동안 데이터를 캐싱 했으므로 페이지 새로 고침이 작동하지 않습니다. 브라우저를 닫을 때만 작동합니다 (때로는).
직렬화
당신이 세션 정보가 다른 하나 개의 서버에서 전송해야합니다 (더 많은 서버를 추가 의미) 웹 서버를 확장하고 있습니다. out-of-process 캐시 (예 : MemCache 또는 SQL Server)를 사용해야합니다. 작업 단위 개체는 직렬화 및 비 직렬화가 어렵거나 불가능합니다. 따라서 원하는 경우 확장 할 수 없습니다. 당신이 직장 패턴의 장치에서 세션의 라이프 스타일 당을 사용하지 않을 것이기 때문
요약
예는 극단적이다. 그러나 여전히 문제를 명확하게 설명하고 있습니다. 세션 당 라이프 스타일은 서비스가 매우 오래 유지되기 때문에 애플리케이션의 메모리 사용 공간을 늘립니다. 이러한 서비스를 사용하여 데이터를 캐시하는 경우 성능이 향상 될 필요가있을 수도 있지만 캐시가 오래 될 수 있습니다. DTO는 종종 쉽게 직렬화 할 수 있지만 등록하는 서비스는 DTO를 보유하지 않습니다. 즉, 직렬화 가능한 세션 객체가 수평 확장되어야하므로 스케일 아웃 할 수 없습니다.
그래서 서비스에 세션 별 라이프 스타일을 사용하는 대신, 싱글 톤으로 등록 될 수 있도록 무국적 인 서비스를 빌드 해보십시오. 필요한 사용자 특정 데이터는 HTTP 세션에서 요청할 수 있습니다.
수치스러운 ASP입니다.NET은 Session 내에서 객체를 직렬화 할 수 없도록합니다. 이는 프로세스 내에서 저장 될 때조차도 ... 초기부터 이러한 동작을 피하는 대신 확장 불가능한 방식으로 웹 프로젝트를 시작하도록 유도합니다. –
@MiguelAngelo : 동의합니다. 이것이 프로덕션이 그렇게하지 않는 경우에도 out-of-proc 캐시를 사용하도록 개발자 환경을 구성하는 이유입니다. 그렇게되면 개발 중에 실패 할 수 있습니다. – Steven