On 3/2/2018 10:39 AM, Christopher Schultz wrote: > The problem is that I'm updating the index after my SQL UPDATE(s) have > run, but before my SQL COMMIT occurs. I have had a problem where the SQL > fails and rolls-back, but the solrClient is not rolled-back. > > I'm a little wary of rolling-back Solr because, as I understand it, the > client itself doesn't carry any transactional information. That is, it > should be a shared-resource (within the web application) and indeed, > other clients could be connecting from other places (like other app > servers running the same application). Performing either commit() or > rollback() on the Solr client will commit/rollback *all* writes since > the last commit, right?
Correct. Relational databases typically keep track of transactions on one connection separately from transactions on another connection, and can roll one of them back without affecting the others. Solr doesn't have this capability. The reason that it doesn't have this capability is that Lucene doesn't have it, and the majority of Solr functionality is provided by Lucene. If updates are happening concurrently from multiple sources, then there's no way to have any kind of meaningful rollback. I see two solutions: 1) Funnel all updates through a single thread/process, which will not move on from one update to another until the final decision is made about that update. Then rolling back becomes possible, because there is only one source for updates. The disadvantage here is that this thread/process becomes a bottleneck, and performance may suffer greatly. Also, it can be a single point of failure. If the rate of updates is low, then the bottleneck may not be a problem. 2) Have your updating software revert the changes "manually" in situations where the SQL change is rolled back ... by either deleting the record or sending another update to change values back to what they were before. Thanks, Shawn
