sijie commented on a change in pull request #727: Issue 693: add interface and 
implementation of LedgerEntries
URL: https://github.com/apache/bookkeeper/pull/727#discussion_r152548916
 
 

 ##########
 File path: 
bookkeeper-server/src/main/java/org/apache/bookkeeper/client/api/LedgerEntries.java
 ##########
 @@ -0,0 +1,52 @@
+/**
+ * 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.bookkeeper.client.api;
+
+import java.util.Iterator;
+
+/**
+ * Interface to wrap the entries.
+ *
+ * @since 4.6
+ */
+public interface LedgerEntries extends AutoCloseable {
+
+    /**
+     * Gets a specific LedgerEntry by entryId.
+     *
+     * @param entryId the LedgerEntry id
+     * @return the LedgerEntry, null if no LedgerEntry with such entryId.
+     */
+    LedgerEntry getEntry(long entryId);
+
+    /**
+     * In this, It does not retain the ByteBuf references for the entries in 
this LedgerEntries.
+     * The caller who calls {@link #iterator()} should be careful for not 
releasing the references.
+     *
+     * @return the iterator of type LedgerEntry
+     */
+    Iterator<LedgerEntry> iterator();
+
+    /**
+     * In this, It retains the ByteBuf references for the entries in this 
LedgerEntries.
+     * The caller who calls {@link #retainIterator()} is responsible for 
releasing the retained references.
+     *
+     * @return the iterator of type LedgerEntry that has been retained
+     */
+    Iterator<LedgerEntry> retainIterator();
 
 Review comment:
   why people need retainSlice for a bytebuf? A slice is essentially an 
iterator for the shared buffer. 
   
   There are use cases for this - for example, if you are building a service, 
which would cache LedgerEntries, there might be multiple readers will read 
those cached LedgerEntries, they would need different iterators on iterating 
the entries. The readers would retain the iterator, and release after they 
finish iteration. The cache will release its held reference when a 
LedgerEntries is evicted from the cache. A correct reference counting behavior 
should be provided when the caller attempts to create iterators.
   
   If you just only provide iterator(), you have to do two rounds of 
iterations. First round, you get an iterator to retrieve ledger entries, retain 
the reference count and add those entries to a list, then return a brand new 
iterator. Second round, your application will iterate over the new iterator. 
This introduces unnecessary complexity.
   
   again, if you are just viewing this from a single user application 
perspective, you don't need `retainIterator()`. but if you are thinking this 
from a shared use case, an iterator for a LedgerEntries is essentially a 
`slice` for a ByteBuf. The reasons why ByteBuf needs a `retainedSlice()` apply 
here.
   
   again, I see this can simplify a lot of things for applications. However I 
am not going to make a strong case here. I don't see it is a correctness 
debate, it is more a convenient util function. If you feel strong about that, I 
am fine with removing it.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to