On Wed, Oct 20, 2010 at 3:27 PM, Ted Dunning <ted.dunn...@gmail.com> wrote:
> These corner cases are relatively rare, I would think (I personally keep > logs around for days or longer). > A concern I would have is that it does add complexity, would be hard to debug... > Would it be possible to get a partial solution in place that invokes the > current behavior if logs aren't available? Seems like it's possible. The issue of finding a viable solution (one where, for example, the memory overhead is limited) is still an issue though. In the end it wouldn't really help the end user, given they would still have to code for this corner case. Patrick > On Wed, Oct 20, 2010 at 10:42 AM, Patrick Hunt <phu...@gmail.com> wrote: > > > Hi Ted, Mahadev is in the best position to comment (he looked at it last) > > but iirc when we started looking into implementing this we immediately > ran > > into so big questions. One was what to do if the logs had been cleaned up > > and the individual transactions no longer available. This could be > overcome > > by changes wrt cleanup, log rotation, etc... There was another more > > bulletproof option, essentially to keep all the changes in memory that > > might > > be necessary to implement 22, however this might mean a significant > > increase > > in mem requirements and general bookkeeping. It turned out (again correct > > me > > if I'm wrong) that more thought was going to be necessary, esp around > > ensuring correct operation in any/all special cases. > > > > Patrick > > > > On Wed, Oct 13, 2010 at 12:49 PM, Ted Dunning <ted.dunn...@gmail.com> > > wrote: > > > > > Patrick, > > > > > > What are these hurdles? The last comment on ZK-22 was last winter. > Back > > > then, it didn't sound like > > > it was going to be that hard. > > > > > > On Wed, Oct 13, 2010 at 12:08 PM, Patrick Hunt <ph...@apache.org> > wrote: > > > > > > > 22 would help with this issue > > > > https://issues.apache.org/jira/browse/ZOOKEEPER-22 > > > > however there are some real hurdles to implementing 22 successfully. > > > > > > > > > >
