Hey Jonathan,

This part of the code base may need some extra thinking. There are
currently ways of using fail-retry strategies provided by TinkerPop for
cases where commits generate exceptions (Transaction.submit()). This is
quite a common occurence actually, think Titan for instance. So implicitly,
TP is expecting failing commits to throw exceptions.
Although, like you mention, there are no pre-defined exceptions. You can
either specify which exceptions to retry on or retry on all exceptions.
This has some drawbacks that I plan on highlighting via a couple of JIRA
tickets (it's getting late here so I'll be adding those tomorrow) but the
main gist of it is that there's a lack of consistency in this area and
things tend to get very implementation specific.

If you've got any ideas and suggestions we're all ears.

Cheers,
Dylan.

On Sun, Nov 29, 2015 at 12:06 AM, Jonathan Ellithorpe <[email protected]>
wrote:

> Hi all,
>
> I'm working on an implementation of TP3 on system that uses optimistic
> concurrently control. In this system a transaction commit is not guaranteed
> to succeed. It appears, though, that since Transaction.commit() returns
> void, and there are no pre-defined exceptions that express a commit
> failure, the Transaction interface was not designed to support occ. Is this
> correct? Are there plans in the future for supporting OCC? This could
> potentially mean some non-trivial changes to the unit tests...
>
> Jonathan
>

Reply via email to