When we update a service provider to include or exclude a container, this triggers updating the Selections of all Configurations in the service provider.
The serialized RDF of a Selections with 1 million elements takes about 250MB to transfer to LQE. LQE is also capable of querying several resources in parallel so it is possible to have several Selections queried at the same time.
Obviously all of this takes a lot of memory and a lot of network traffic.
Has anybody here already dealt with big Selections resources when working with TRS / LQE?
Are there some recommendations on how to deal with such large Selections resources? Paging maybe?
When a client requests a resource that an OSLC Service considers to be too large to return in one response and the client has not indicated that it desires paging (via oslc.paging or oslc.pageSize), the OSLC Service MAY redirect the client to a representation that contains partial information about the resource. [CORE-36]
When the OSLC Service opts to redirect the client to a partial representation, it MUST return an HTTP Status 302 redirect to a URL that includes either oslc.paging, or oslc.pageSize, or both. [CORE-37]
Yes, using OSLC core paging is the way to go for large resources such as oslc_config:Selection resources. It’s what DOORS Next and Engineering Test Manager do for their selection resources.
