Yes -- autoCommit works just the same as if you had a timer in your app
committing. You have to turn it off if you want to maintain the ability
to roll back predictably.
-Mike
On 01/20/2015 09:19 AM, Clemens Wyss DEV wrote:
Thanks Mike,
but a key difference is that when one client commits, all clients will see the
updates
That's ok.
What about the <autoCommit>-setting(s) in solrconfig.xml. Doesn't this mean
that after adding x elements (or after a certain timeframe), the changes are commited
and hence no more rollbackable? Or do the autoCommit-settings only affect/control the
commits to the Solr-transaction.log?
-Clemens
-----Ursprüngliche Nachricht-----
Von: Michael Sokolov [mailto:msoko...@safaribooksonline.com]
Gesendet: Dienstag, 20. Januar 2015 14:54
An: solr-user@lucene.apache.org
Betreff: Re: transactions@Solr(J)
On 1/20/2015 5:18 AM, Clemens Wyss DEV wrote:
http://stackoverflow.com/questions/10805117/solr-transaction-managemen
t-using-solrj Is it true, that a SolrServer-instance denotes a
"transaction context"?
Say I have two concurrent threads, each having a SolrServer-instance "pointing" to the
same core. Then each thread can add/update/delete documents without "affecting" the other
thread/SolrServer-instance?
Must <autoCommit> be switched off for this to work?
Solr does not provide transactional isolation like you might be familiar with
from a relational DB. There are commit and rollback, so no updates are seen
until a commit (including autocommit), but a key difference is that when one
client commits, all clients will see the updates, since index readers are
shared, not associated with a specific client. The underlying Lucene index has
the ability to maintain an open reader even after another writer has issued a
commit, but this isn't accessible via Solr.
-Mike
