Reservoirs and parallelism

push 이벤트, pull data 모델 그리고 일반적인 멀티쓰레드 처리 때문에 repository 데이터의 전체 변경 이력을 알수 없을수도 있게 의도적으로 설계된 것이다. 대부분의 경우( 특히 앱의 UI 업데이트 )에는 가장 최신의 데이터가 중요 하지만, 데이터의 모든 변경 이력을 알아야 한다면, Agera 는 이러한 상황에서 유용하게 쓸수있는 repository의 하위 개념인 Reservoir 을 제공한다.

Reservoir는 큐의 일종으로 볼수있는데, 큐의 반응형(reactive) 버전이다. 데이터는 reservoir 에 들어갈수 있는데, reservoir 은 reciever interface 를 가지기 때문에 데이터가 업데이트된 사항을 알릴수 있다. 또한 reservoir 의 repository( 정확히는 공급자 ) 인터페이스를 이용하여 같은 데이터를 꺼내올수 있다. reservoir 에 접근하는 것은 모두 동기식 이기 때문에, 같은 데이터의 인스턴스를 동시에 가질수 없다. ( 이때 인스턴스란 repository 에 저장된 객체이고, 만약에 같은 참조를 갖는 객체를 여러번 넣더라도 Reservoir 에서는 각자 다른 인스턴스를 가지게 된다. ) 리턴된 값은 Result 로 감싸져서 반환되는데, 만약에 repository 가 비었다면 Result.absent() 로 failure 를 받게 된다.

reservoir 은 각 데이터의 부분을 처리해야만 하는 반응형 동작에서 완벽하게 쓰일수 있다. reservoir 를 그것의 이벤트소스 들과 .attemptGetFrom(reservoir).orSkip()의 데이터 흐름 처리 사용하기에 적합하다면, 이런 반응성은 compiled repository 를 이용하여 구현될수 있다. 변경사항을 관찰하는 reservoir 과 compiled repository 의 관계는 repository 가 동작하는 동안 reservoir 에 저장된 데이터를 지속적으로 소비한다

단순한 병렬 처리는 앞서 말한 데이터소스와 이벤트소스로써 reservoir 를 사용한 reservoir 과 여러 인스턴스를 가지지만 동일한 compiled repositories 를 이용하여 처리 할수 있다. Job 들이 reservoir 에 추가될수 있고, 각 repository 들은 그들의 분리된 데이터 처리 흐름에서 잡들을 처리하기 위해 꺼내올수 있다. 이러한 repository 들은 스레드 Executor 에 각각 들어가서 다른 worker Loopers 에서 처리 됨으로써 병렬 처리를 할수있다.

[원본] https://github.com/google/agera/wiki/Reservoirs-and-parallelism