3
Google 사이트에는 RavenDB가 사용됩니다. 사이트는 대량의 데이터를 처리 할 수 있도록 모든 데이터를 메모리에로드합니다 (그리 많지는 않음). 우리는 정기적으로 DB (RavenDB + sqlserver)에서 새 데이터가 있는지 여부를 확인하는 백그라운드 스레드에 데이터를로드하고, 데이터가 메모리에로드되는지를 확인합니다.ravendb 장기 실행 세션
우리는 세션 당 RavenDB에 대한 30 개의 질의에 대한 귀찮은 요청 제한을 해결하기 위해 많은 노력을했습니다. Raven은 check/load 루프를 한 번 반복 한 후에 세션을 "재설정"할 수있는 메커니즘이 없기 때문에 Structuremap에 알려줄 방법이 없습니다. 실제로 우리는 우리가 꼼짝 못하게되기 전에 여전히 같은 스레드.
결국 저는 리포지토리가 구조 맵이로드되는 RavenSessionProxy를 사용하도록 로드맵/리치 루프 (재설정 할 때 새로운 문서 세션을 수동으로 인스턴스화 함)로 재설정 할 수 있도록 아키텍처를 변경했습니다.
이것이 실제로 유일한 방법입니까? 레이븐 내에 "헤이 MR 세션, 나는 지금 너와 끝났어, 너 자신을 플러시하고 다음에 내가 당신에게 전화 할 때 신선하고 준비가되어있다"라고 말하는 메커니즘이 없습니까? 아니면 Structuremap "이봐, SM! IDocumentSession을 요청할 때 새 세션을 가져 오면이 오래된 세션에 지쳤습니다. "
MaxNumberOfRequests는 문제를 단지 연기 할 것이고, 요점은 내가 계속 세션을 영원히 지속시키고 싶을 뿐이며 주기적으로 재설정한다는 것입니다. * 모든 * 유스 케이스는 단일 요청에 최대 30 개의 쿼리를 수행 한 다음 죽어가는 경우가 아닙니다. 내 배경 로딩은 영원히 살기로되어있다. – AndreasKnudsen