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, 02 May 2012 06:32:55 GMT


Per Steffensen commented on SOLR-3178:

{quote} .bq    since I offer the "semanticsMode" property in updatehandler {quote}

{quote} Seems like this should be up to the client... why wouldn't update semantics be handled
on a per-request basis? {quote}

Maybe we misunderstand each other a little bit. I just agree that people want Solr to provide
different kinds of semantics - some want strict version-check, some dont, some will have an
fire-and-forget approach, some will not. I just ment to say that for some of those types of
semantics you want server-side Solr to behave in a certain way. For that you probably need
a configuration telling the server how to behave. I have introduced that for updates with
the "semanticsMode" config on updatehandler.

I believe, when it comes to whether you want strict unique-key-constraint- and version-checks
or not, it is probably something you want to configure server-side, so that you can control
the possibilities of your clients. Not all Solr-based systems will have complete control over
all its clients, and then it is nice on server-side to be able to say (using semanticsMode):
* consistency: I dont want you as a client to make updates to documents, without even having
read the existing document first (and merged your updates into that), and I dont want you
to be able to overwrite changes to that document that happend to be made between the time
you read it and the time you provided your updated version. And I dont want you to incidentally
overwrite an existing document, if your intent was to create a new one.
* classic: All updates just go right into Solr, but you risk overwriting exsisting stuff
* classic-concistency-hybrid: You can do both consistency and classic updates, be casefull
when doing classic updates
I believe this kind of control belongs in a server-side config, because it is a way of "protecting"
your data against badly written clients.

With respect to whether you want to do fire-and-forget or not, that should be up to the client,
but it kinda is by definition - basically just ignore results. But fire-and-forget strategy
on clients is really not worth much, if you have to wait for the server to reply when you
do updates (like you have to do today). SOLR-3383 will provide a all-async client SolrJ API
(Future-based all the way) so that you can really just "fire", and if you intent is to "forget"
anyway, then you can move on immediately after your "fire" without waiting for the server
to reply.

That is not the reason we made SOLR-3383 though. It is because we want to be able to get results
back when using ConcurrentSolrServer, and that requires a Future-based request API.

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-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