Uhhhm, the soft/hard commit settings are global, not configured in each update handler.
How are updates being done? Because if you're using SolrJ, you can just use the server.add(doclist, commitwithin) and it'll just be handled automatically. True, putting a 2 second commitwithin on an online update would pick up some batch updates that happened to come in, but that's probably OK. I'd also be sure that the 2 second requirement is real. Soft commits aren't as expensive as hard commits with openSearcher=true, but they aren't free either. At that fast a commit rate you probably won't get much benefit out of the top-level caches, and you'll be warming an awful lot. FWIW, Erick On Sun, Nov 30, 2014 at 12:32 PM, danny teichthal <dannyt...@gmail.com> wrote: > Hi, > On our system we currently initiate a soft commit to SOLR after each > business transaction that initiate an update. Hard commits are automatic > each 2 minutes. > We want to limit the explicit commit and move to autoSoftCommit. > > Because of business restrictions: > Online request should be available for searching after 2 seconds. > Update from batch jobs can be available after 10 seconds. (maybe more, > currently on discussion). > There are some transactions that must be available immediately. > > Question > I thought about creating 3 different update handlers, each containing a > different autoSoftCommit configuration. Is this an acceptable solution, are > there any downsides in using multiple update handlers? > > Thanks,
