okta
Question about thread safety of `PaginationUtil`
A recent PR introduced a new pagination mechanism, deprecating the use of PagedList.
Seeing as the new pagination mechanism relies on shared state stored in the API client, namely responseHeaders, I wonder if this affects thread-safety guarantees of the client, and the possibility to share a client instances across independent threads in an application.
As I understand it, PagedList avoids this issue because it is contructed directly from the API response without relying on shared state.
I appreciate it if you're able to shed some light here. Thanks!
@biochimia Thanks for posting!
This is an interesting question. The only way the ApiClient knows the pagination information is from the response headers. Thought the ApiClient by itself is thread safe, the use of PaginationUtil in a multithreaded environment is not guaranteed to be thread-safe.
General Note: The use of the issues section of this repository is reserved for issues/bugs/feature requests and NOT intended for discussions/questions. Please use https://devforum.okta.com/ for questions.
Thank you for replying, @arvindkrishnakumar-okta. Apologies if this is not the right forum for this sort of question. It felt like other users of the GitHub project would benefit from this.
Can you further confirm that use of the (now deprecated) PagedList did not suffer from this thread-safety issue?
It seems that such a break in thread-safety guarantees of PaginationUtils should be noted prominently.
In particular it is stated in project documentation that ApiClient is thread-safe, and can be shared to benefit from connection pooling. It would seem that accessing any paginated endpoint breaks this guarantee and forces SDK users to isolate client instances, at least without using the deprecated PagedList functionality.
@biochimia Thanks for the response! Sorry for the delayed response - the PagedList is/was not guaranteed to be thread safe and like you noted this will be documented.