[
https://issues.apache.org/jira/browse/SOLR-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803636#comment-13803636
]
Yonik Seeley commented on SOLR-5374:
------------------------------------
It seems like concurrency is not yet handled? Under concurrent updates, the
patch won't guarantee the correct ordering.
{code}
Thread 1: update with version=10, check version on doc A, returns 5
Thread 2: update with version=11, check version on doc A, returns 5
Thread 2: update completes with version 11
Thread 1: update completes with version 10
{code}
There's going to need to be either some sort of synchronization or optimistic
concurrency.
Also, it looks like the current code assumes it's running on the leader? The
realtime-get done is local only, and if you hit the wrong shard with the
request, it will look like the doc doesn't exist yet.
> Support user configured doc-centric versioning rules
> ----------------------------------------------------
>
> Key: SOLR-5374
> URL: https://issues.apache.org/jira/browse/SOLR-5374
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Hoss Man
> Attachments: SOLR-5374.patch
>
>
> The existing optimistic concurrency features of Solr can be very handy for
> ensuring that you are only updating/replacing the version of the doc you
> think you are updating/replacing, w/o the risk of someone else
> adding/removing the doc in the mean time -- but I've recently encountered
> some situations where I really wanted to be able to let the client specify an
> arbitrary version, on a per document basis, (ie: generated by an external
> system, or perhaps a timestamp of when a file was last modified) and ensure
> that the corresponding document update was processed only if the "new"
> version is greater then the "old" version -- w/o needing to check exactly
> which version is currently in Solr. (ie: If a client wants to index version
> 101 of a doc, that update should fail if version 102 is already in the index,
> but succeed if the currently indexed version is 99 -- w/o the client needing
> to ask Solr what the current version)
> The idea Yonik brought up in SOLR-5298 (letting the client specify a
> {{\_new\_version\_}} that would be used by the existing optimistic
> concurrency code to control the assignment of the {{\_version\_}} field for
> documents) looked like a good direction to go -- but after digging into the
> way {{\_version\_}} is used internally I realized it requires a uniqueness
> constraint across all update commands, that would make it impossible to allow
> multiple independent documents to have the same {{\_version\_}}.
> So instead I've tackled the problem in a different way, using an
> UpdateProcessor that is configured with user defined field to track a
> "DocBasedVersion" and uses the RTG logic to figure out if the update is
> allowed.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
