If the limit is set to 5, the same output will appear if user 2 attempts to search all numbers that end in "99."
My requirement is, The first five records must be hidden from User 2 because they have already been given to User 1, and I must grant him access to the last five records, which are mentioned below
I appreciate your reply. I am using hibernate search for this implementation from Elasticsearch.
As a result, I made an attempt at a fix by adding a new field named "lock state" and using that state value in addition to the primary search criteria. As a result, once a response is given to a user, I immediately update the "lock state" column in the database, which is then automatically synced with the elastic cluster. So that the second user won't receive the same response.
The issue with this strategy is that hibernation search requires a minimum of 1 second to complete this auto-syncing to the elastic cluster; however, if there was a way for me to complete this immediately without degrading performance, the issue would be resolved.
There is a slightly different way of handling this. Instead of having your "lock state" update Elasticsearch, you could have the lock state be an additional "NOT" filter on your Elasticsearch query.
In your example use case.
Assuming the default "lock state" is empty. User 1, would run their search to find the first 5 numbers that end in "99", resulting in:
Your app could then update the "lock state". User 2 could then run their same query, but this time the query that gets run, includes the values in the "lock state" as a NOT clause in the Elasticsearch query. This should in theory result in User 2 getting the results:
And this should effectively have no real "performance issues", as this is mainly just an adjustment to the query, you're running rather than the actual underlying data.
Ok. Even with this approach , there is a delay to update to Elasticsearch about "lock state" value to use in NOT query. Due to this delay the user 2 will have the chance to get the same response given to user 1. Is there a way to avoid this 1 second delay ?
Hmm, I'm not sure how you're implementing your "lock state", but in theory, if you're app is a single deployment, you can just track the "lock state" in the app itself, and thus really not have a delay. If the app is distributed, I don't think there is any real "solution" here. No, matter the approach, there will always be a chance that there will be some time gap between the "lock state" being updated and users querying the data. But, you should also really consider the use case. Will a 1 second gap really matter? Will your app have usage that will consistently see multiple users running similar queries within 1 second of each other? Will it really matter if occasionally users see similar results? The issue seems more like an application implementation issue at this point (I'm not really aware of any sort of database that offers this functionality out of the box).
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.