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
