"요청 당 세션"패턴이 캐시를 활용합니까? ("세션 당 세션"또는 "요청 당 세션")

Question

요즘 웹 응용 프로그램에서 처음부터 새로운 응용 프로그램을 빌드합니다.
(기술은 Asp.Net하고 내가 사용하고있어 ORM은 Entity Framework이다.이 중요한 경우) 요청 당 널리 사용되는 패턴 세션이 정말 좋은 경우

내가 불확실 해요.
이 패턴의 장점은 데이터베이스 세션이 너무 크고 비효율적 일 때까지 캐시가 증가하지 않는다는 것입니다.

그러나 모든 요청마다 새로운 세션이 너무 많지 않습니까? 즉, 모든 서버 호출이 캐시를 재설정한다는 것을 의미합니다. 자동 완성과 같은 간단한 아약스 요청에도 새로운 캐시가 있습니다. 사실 캐시가 재설정되는 모든 키 스트로크에 해당합니다.

한 요청에서 동일한 object-entity-row를 쿼리 할 가능성이 적습니다.

아니요 세션 당 세션은 더 나은 패턴입니까? 두 장점을 모두 가지고 있습니다.

1. 캐시가 영원히 성장하지 않습니다.
캐시가 실제로 사용할 수 있습니다
2. ...

그래서 ... 왜 요청 당 세션이 널리 사용되며, 세션 당 세션이 아닌가요?

---

부연 설명 : 내가 ORM 세션을 썼을 때

1. 은 모두 NHibernate's session 및 EntityFramework's DbContext에 적용됩니다.
2. 각 요청마다 세션 \ dbcontext의 플러시 - 커밋 - SaveChanges를 의미합니다.

Answer 1

요청 패턴 당 세션은 ORM을 사용할 때보다 자연스럽고 견고합니다. 더티 엔티티를 확보 할 확률이 적어지고 예측 가능한 자원 관리가 더 많습니다.

당신이 맞다면 세션 당 세션보다 DbContext 인스턴스가 데이터 수정없이 응용 프로그램에서만 사용될 수 있다는 것을 의미합니다. 그렇지 않으면 다른 요청이 데이터 수정을 수행하는 동안 요청에 의해 예기치 않은 데이터가 전송됩니다. 또한 Entity Framework 컨텍스트가 스레드 안전하다고 확신하지 않습니다 - 요청을 처리하는 동안 다중 스레드가 발생합니다.

필자는 완전히 확신하지는 않지만 Entity Framework는 예상대로 캐시 (== identity mapping)를 사용하지 않는다고 생각합니다. 엔티티 집합을 선택할 때 모든 데이터가 캐시에 있더라도 데이터베이스를 쿼리하므로 새로운 엔티티 구성은 피할 수 있지만 ID 맵에서 기존 엔티티 사용은 피할 수 있습니다.

캐싱에는 다른 솔루션이 있으며 더 좋습니다.

Answer 2

나를 위해, 모든 작업 단위를 단일 요청으로 제한하여 일관성을 유지하는 것이 중요합니다. 일이 잘못 될 때 세션 당 세션이 어떻게 작동하는지 잘 모르겠습니다.

예를 들어, 여러 요청이 처리 된 후 커밋에 대한 낙관적 동시성 예외가 발생하면 어떻게 할 것입니까? 그 시점에서 몇 가지 병합 충돌이있을 수 있습니다.

요청 당 세션은 충돌 노출을 제한하고 요청 범위에서 작업 단 위를 만듭니다.