git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Inconsistency in Handle based APIs - Specifically "close"


> Is implementing Closable a "valueable" feature for us in the new API ?  (I
> think the answer is 'yes')

I'm not so sure how useful Closeable is here. It is handy in tests,
but in production code you are never going to use the
try-with-resources pattern, as you'll be using async calls for
everything else. I think people not waiting on a returned
CompletableFuture is a bigger issue, but maybe even that isn't
important (see below).

> There was a discussion about introducing some CompletableFuture seal()
> method, which would be more like current close().

Yes, there was a BP which just ended going around in circles and I got
frustrated and closed it. Part of the problem was there were many
things being discusses at the same time, so now I just want to
concentrate on the close inconsistency.

> With this approach we should document very well that a seal() must be
> called and about the risks of not calling that seal()

What are those risks? If I never called close() or seal() on my
WriteHandle, what is the worst thing that could happen? I don't think
much bad could happen at all, because not calling close or seal is the
same as crashing before you do. So not calling it means that the next
person to open the ledger has to deal with it, which is a latency hit
for them. Even in the case where you are rolling your ledger, and then
continue writing to a new one, I don't think there's a problem. If you
don't close, then any entries that have been successfully written will
continue to be successfully written, so whether you record this in the
metadata isn't important. And you don't need to fence, because in this
case you are the writer.

Anyhow, I'm not arguing for a particular solution here, just
highlighting that the operation of "close" isn't as vital as it has
always appeared to be.

Cheers,
Ivan