Feature Request: OptimisticLockingExecption

[ralfhergert]

Write operations on the MarkLogic database can run into an error due to optimistic locking. In our implementation we want to deal with this sort of error and are trying to implement a retry-mechanism. Our problem is, that the error due optimistic locking is hard to distinguish from all the other errors (connection issues, authorization issues, syntactical problems in the request, ...) because for all of them only a FailedRequestException is thrown. The only(?) way to get the underlying error is currently a string comparision on the exception's message, which is a brittle approach.

This is how we currently detect an error due to optimistic locking:

try {
    manager.write(documentDescriptor, writeHandle);
} catch (FailedRequestException e) {
    // catch errors due optimistic locking and re-attempt the update.
    if (e.getMessage().contains("RESTAPI-CONTENTWRONGVERSION")) {
        /* snipped: we retry by reading the document again, manipulate it and try to write it again. */
    }
}

(manager is here an XMLDocumentManager)

Our feature request is: Is it feasible to create an OptimisticLockingException? The OptimisticLockingException could be a subclass of the already existing FailedRequestException, then no APIs have to be changed. We could simplify and harden our implementation to:

try {
    manager.write(documentDescriptor, writeHandle);
} catch (OptimisticLockingException e) {
    /* snipped: we retry by reading the document again, manipulate it and try to write it again. */
}

Thank you in advance!

[rjrudin]

Thanks @ralfhergert , I'll do some research on this today and get back to you soon.

[rjrudin]

@ralfhergert Sorry for the delay, still have analyzing this on my to-do list!

[rjrudin]

@ralfhergert Turns out we have several tests for this feature already - all of which are doing what you're doing too! We somewhat surprisingly don't have any subclasses of FailedRequestException yet, but I see no issue with starting that pattern.

There are two similar codes:

• RESTAPI-CONTENTNOVERSION
• RESTAPI-CONTENTWRONGVERSION

Full list of REST API error codes is at https://docs.marklogic.com/11.0/guide/messages/RESTAPI-en .

I am wondering if it would be beneficial to use class names of e.g. ContentNoVersionException and ContentWrongVersionException that don't attempt to abstract over the error code. Would those be self-documenting enough to achieve your goal of both 1) not having to do a string check, and 2) making your code easier to understand?

[ralfhergert]

Hi @rjrudin, thanks for your response. Yes, the intended exceptions ContentNoVersionException and ContentWrongVersionException would work for us. They would achieve that we no longer have to implement the technical detail of "having to know the ML REST error strings". And they would allow us to catch the exceptions without further probing them for the underlying cause. - Looking forward to it. :)

[rjrudin]

Got it - we're doing a 6.2.1 release soon, I'm leaning towards sneaking this in even though it's technically a minor enhancement. The exception message won't change, just the class type, and it'll be a subclass of FailedRequestException.

[rjrudin]

Being addressed via #1590

[rjrudin]

Will be in 6.3.0, which will be released shortly.