Thanks Pieter that's very useful. Jonathan: Yeah at the moment the submit is as you noticed. Just storing a workload with some convenience methods. There's been discussion around what input is accepted in defining the workload here: https://issues.apache.org/jira/browse/TINKERPOP3-741 but the gist remains the same.
We've also bounced back and forth with a few of the retry concepts but never came to any worthwhile conclusions. I've created the following issue in JIRA which if doable could unlock some other possibilities: https://issues.apache.org/jira/browse/TINKERPOP3-1004 On Sun, Nov 29, 2015 at 8:14 AM, pieter <[email protected]> wrote: > Hi, > > For interest, > > > http://docs.oracle.com/javaee/6/api/index.html?javax/transaction/UserTransaction.html > http://docs.oracle.com/javaee/6/api/javax/transaction/package-summary.html > > UserTransaction.commit() also returns void. > They do however define exception classes. > > Cheers > Pieter > > On 29/11/2015 01:46, Dylan Millikin wrote: > > 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 > >> > >
