On 22.8.14 4:31 , Alex Parvulescu wrote:
Hi, Following OAK-2039 there was a discussion around the current design of the #checkpoint apis. [0] It looks a bit confusing that you can call the apis to create a checkpoint and get back a reference but when retrieving it, it might not exist, even if the calls are back to back.
Reading the Javadoc carefully this is to be expected. However I think this could be improved. Either by making the Javadoc for #checkpoint more explicit about it or by reflecting it in the return value.
Instead of returning null for the later option we could also return a constant value representing a not available checkpoint. With that client code wouldn't need to change but could check the returned value if desired.
Michael
With OAK-2039 I've added some warning logs when a checkpoint cannot be created but a ref is still returned, to understand if this is a system load problem, or something more profound. I believe that nobody has any issues with the #retrieve method, all the confusion is really about the #checkpoint parts, currently marked as '@Nonnull'. Alternatives mentioned are - return null if the checkpoint was not created - throw en exception I vote -0 for the change, I believe that making this more complicated than it needs to be (more null checks, or a try/catch) doesn't really benefit anybody. If there are thoughts around how this should change, please feel free to join in. best, alex [0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/NodeStore.java#L124
