Make Find Bar result ranking user specific (MGNLPER-72)

[MGNLPER-77] Make sure JCR search and multiple threads play well together Created: 16/Jan/19  Updated: 07/Sep/22  Resolved: 24/Jan/19

Status: Closed
Project: Periscope
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1

Type: Sub-task Priority: Neutral
Reporter: Federico Grilli Assignee: Cedric Reichenbach
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MGNLPER-165 Search queries are not executed concu... Closed
Template:
Date of First Response:
Sprint: Foundation 2, Foundation 3

 Description   

As creichenbach mentioned while reviewing a related PR:

"Multiple threads trying to get a session on the same workspace will give you badtimes (IIRC throws an exception on the second one). So far it wasn't an issue because we assumed no one would have multiple suppliers for the same workspace in a normal scenario (but this assumption might be flawed on second thought as well, e.g. pages vs. tours).

Now, I think we have two options:

  1. Do everything in a single thread. We had this in the beginning, and it's painfully slow. And if we have multiple Periscope instances, it's still not safe the way it is right now - we'd need a globally single thread.
  2. Protect JCR search with semaphores on a per-workspace basis (one semaphore per workspace, each with limit 1). So if two threads happen to try searching the same workspace at the same time, one would be blocked until the other one is done.

I'd strongly vote for option 2."

Or perhaps use JCR's own LockManager, assuming that helps in our case, which must be verified https://docs.adobe.com/docs/en/spec/jcr/2.0/17_Locking.html


Generated at Mon Feb 12 10:28:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.