lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <>
Subject [jira] [Commented] (SOLR-3178) Versioning - optimistic locking
Date Wed, 09 May 2012 10:19:54 GMT


Per Steffensen commented on SOLR-3178:

Sorry to see that you chose to commit a different patch for this one, making me believe that
you are not going to take my patch in. I really dont understand why, because I think my solution
is at least as good or better in any aspect, and besides that it is more complete, backward
compatible and solves a lot of other issues (SOLR-3173, SOLR-3382 and SOLR-3428) already -
can I ask you to tell me why you made that choice? Maybe what is wrong with our patch since
it is not taken in, what we need to change etc?

Please also elaborate on your plans wrt the other issues 
* Using unique key constraints to protect against overwriting existing data, when intent is
to just insert a new document (kinda what SORL-3173 was thought to be about) - DocumentAlreadyExists
* Even though an document update fails, still try updating the rest of the documents in the
same update request, and therefore the feature of being able to report several errors back
to the client linking each error to a specific document in the request (basically SOLR-3382)
* Nicely "typed" errors so that you as a client can detect which kind of error occurred in
an easier way than guessing from http status code and textual error messages (also SOLR-3382)
* The SOLR-3428 bug

I need to know what to tell my product owners wrt how long we need to run on our own version
of Solr (containing our patches etc.) in our high-throughput and high-concurrency pilot-prod
system and therefore also for how long we need to keep merging changes from Solr trunk in?
And when we can get to contribute additional code - mostly stability/endurance-related bug
fixes. We already gave you the fix for SOLR-3437 but some of our additional fixes are kinda
dependent on some of the stuff in SOLR-3173_3178_3382_3428_plus.patch. Do you have any plans
revealing if we have to wait
* Forever? (= our patch is not going to be committed)
* Weeks/Days? (= you are working on understanding our patch and expect to commit later)
* Or?

Regards, Per Steffensen

> Versioning - optimistic locking
> -------------------------------
>                 Key: SOLR-3178
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: update
>    Affects Versions: 3.5
>         Environment: All
>            Reporter: Per Steffensen
>            Assignee: Per Steffensen
>              Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, update, versioning
>             Fix For: 4.0
>         Attachments: SOLR-3173_3178_3382_3428_plus.patch, SOLR-3178.patch, SOLR_3173_3178_3382_plus.patch
>   Original Estimate: 168h
>  Remaining Estimate: 168h
> In order increase the ability of Solr to be used as a NoSql database (lots of concurrent
inserts, updates, deletes and queries in the entire lifetime of the index) instead of just
a search index (first: everything indexed (in one thread), after: only queries), I would like
Solr to support versioning to be used for optimistic locking.
> When my intent (see SOLR-3173) is to update an existing document, I will need to provide
a version-number equal to "the version number I got when I fetched the existing document for
update" plus one. If this provided version-number does not correspond to "the newest version-number
of that document at the time of update" plus one, I will get a VersionConflict error. If it
does correspond the document will be updated with the new one, so that "the newest version-number
of that document" is NOW one higher than before the update. Correct but efficient concurrency
> When my intent (see SOLR-3173) is to insert a new document, the version number provided
will not be used - instead a version-number 0 will be used. According to SOLR-3173 insert
will only succeed if a document with the same value on uniqueKey-field does not already exist.
> In general when talking about different versions of "the same document", of course we
need to be able to identify when a document "is the same" - that, per definition, is when
the values of the uniqueKey-fields are equal. 
> The functionality provided by this issue is only really meaningfull when you run with
"updateLog" activated.
> This issue might be solved more or less at the same time as SOLR-3173, and only one single
SVN patch might be given to cover both issues.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message