Hi, Thanks for clarifying, I have been thinking that full RAMbuffer triggered a commit, but I now see the difference between a flush of a segment and further down the road a commit which then links all these intermediate segments with that particular commit.
So ROLLBACK closes the writer but instead of persisting docs with a commit, it cleans up all uncommitted (flushed or not) doc and files. This is actually not as bad as I thought. So the main catch with ROLLBACK then is if COMMITs are done by other clients or if autoCommit or commitWithin is being used. However, after reading http://blog.mikemccandless.com/2012/03/transactional-lucene.html I see that it is possible to tag COMMITs with userData, so we could make the rollback actually roll back to the last explicit commit (still assuming you're the only client around) if, say AutoCommits and CommitWithins are tagged as such. So I'm OK if you guys rather want to start improve the ROLLBACK API instead of deprecating it. A client should be certain that ALL docs since last commit gets rolled back, else the rollback command must fail. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 9. mai 2013 kl. 20:49 skrev Mikhail Khludnev <mkhlud...@griddynamics.com>: > Mark, > thanks for confirming my feeling. > > Hence, I ask for leaving it for "old-school" deployments. However, it's a > good thing to clearly indicate to the user that it's not implemented for > tlog. What about log WARN/ERROR and/or throw an exception with explanation? > > > > On Thu, May 9, 2013 at 10:28 AM, Jack Krupansky <j...@basetechnology.com> > wrote: > This does highlight that rollback is perfectly reasonable for embedded Solr > or other "dedicated", single-node, well-controlled apps, even if it doesn't > work for cloud. > > -- Jack Krupansky > > -----Original Message----- From: Mark Miller > Sent: Thursday, May 09, 2013 1:09 PM > > To: dev@lucene.apache.org > Subject: Re: [Discussion] Discontinue the ROLLBACK command in Solr? > > RAMbuffer doesn't affect this stuff - if you rollback, it rolls back to the > last commit point. Flushed segments are fine. > > - Mark > > On May 9, 2013, at 12:54 PM, Mikhail Khludnev <mkhlud...@griddynamics.com> > wrote: > > Jan, > Could you please clarify current rollback functionality to me? Let's I have > autoCommit disabled, but my RAMbuffer is not huge, hence I have few flushes > after previous commit. if I invoke rollback will it forget about flushed > segments? > > > > On Thu, May 2, 2013 at 12:38 AM, Jan Høydahl <jan....@cominvent.com> wrote: > Hi, > > Many are confused about the rollback feature in Solr, since it cannot > guarantee a rollback of updates from that client since last commit. > > In my opinion it is pretty useless to have a rollback feature you cannot rely > upon - Unless, that is, you are the only client for sure, having no > autoCommit, and a huge RAMbuffer. > > So why don't we simply deprecate the feature in 4.x and remove it from 5.0? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > Solr Training - www.solrtraining.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > -- > Sincerely yours > Mikhail Khludnev > Principal Engineer, > Grid Dynamics > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > -- > Sincerely yours > Mikhail Khludnev > Principal Engineer, > Grid Dynamics > >
