Github user joshelser commented on a diff in the pull request:
https://github.com/apache/incubator-ratis/pull/4#discussion_r214455091
--- Diff:
ratis-logservice/src/main/java/org/apache/ratis/logservice/api/LogWriter.java
---
@@ -0,0 +1,59 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.ratis.logservice.api;
+
+import java.io.IOException;
+import java.nio.ByteBuffer;
+import java.util.List;
+
+/**
+ * Synchronous client interface to write to a LogStream.
+ */
+public interface LogWriter extends AutoCloseable {
+
+ /**
+ * Appends the given data as a record in the LogStream.
+ *
+ * @param data The record to append
+ * @return The recordId for the record just written
+ */
+ long write(ByteBuffer data) throws IOException;
+
+ /**
+ * Appends each entry of data as a new record in the LogStream. If this
method returns
+ * successfully, all records can be considered persisted. Otherwise,
none can be assumed
+ * to have been written.
+ *
+ * @param records Records to append
+ * @return The largest recordId assigned to the records written
+ */
+ long writeMany(List<ByteBuffer> records) throws IOException;
--- End diff --
Right, not intrinsically, but I think that's OK. Raft is making sure that
when the method returns successfully, a majority of the nodes has the writes
which were acked.
For any other case, the client would have to re-read the log to see which
were actually applied. Specifically for HBase, I think that's acceptable -- if
the write to the HBase WAL fails, that flows back to the client and the client
needs to just resubmit the update.
I'm open to suggestions on how we could make this API better; my only
hesitation is that I think I know too little to give the problem adequate
consideration right now. I remember reading a blog by Jay Kreps about how hard
exactly once is.
---
