# Optimizations for big Selections resources when working with TRS / LQE

**URL:** <https://forum.open-services.net/t/optimizations-for-big-selections-resources-when-working-with-trs-lqe/430>\
**Category:** OSLC implementations\
**Created:** [November 9, 2020, 8:03am UTC](https://forum.open-services.net/t/optimizations-for-big-selections-resources-when-working-with-trs-lqe/430 "2020-11-09T08:03:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Frej](https://forum.open-services.net/user_avatar/forum.open-services.net/frej/32/210_2.png) [@Frej](https://forum.open-services.net/u/Frej)\
**Post date:** [November 9, 2020, 8:03am UTC](https://forum.open-services.net/t/optimizations-for-big-selections-resources-when-working-with-trs-lqe/430/1 "2020-11-09T08:03:42Z")

</div>

Hi everyone,

Question regarding LQE.

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?

Thanks 🙂  
Frej.

---

<div class="post-metadata">

**Author:** ![Frej](https://forum.open-services.net/user_avatar/forum.open-services.net/frej/32/210_2.png) [@Frej](https://forum.open-services.net/u/Frej)\
**Post date:** [November 11, 2020, 2:09am UTC](https://forum.open-services.net/t/optimizations-for-big-selections-resources-when-working-with-trs-lqe/430/2 "2020-11-11T02:09:06Z")

</div>

Hi,

I’ve seen this in Core 3.0:

> 4.1.10.5 Provider Response Size Limitations
> 
> 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]

Should I consider this the way to go?

---

<div class="post-metadata">

**Author:** ![DavidJHoney](https://forum.open-services.net/user_avatar/forum.open-services.net/davidjhoney/32/190_2.png) [@DavidJHoney](https://forum.open-services.net/u/DavidJHoney)\
**Post date:** [November 12, 2020, 6:26pm UTC](https://forum.open-services.net/t/optimizations-for-big-selections-resources-when-working-with-trs-lqe/430/3 "2020-11-12T18:26:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Frej](https://forum.open-services.net/user_avatar/forum.open-services.net/frej/32/210_2.png) [@Frej](https://forum.open-services.net/u/Frej)\
**Post date:** [November 13, 2020, 2:22pm UTC](https://forum.open-services.net/t/optimizations-for-big-selections-resources-when-working-with-trs-lqe/430/4 "2020-11-13T14:22:50Z")

</div>

Thanks David. I’ll confirm that to our team 🙂