Hi Dylan, that clarifies it for me. Reading the comments I hadn't understood the use of this submit() method and had hence overlooked it and the corresponding Workload class... It seems like submit is a bit of an odd way of describing what this method is doing, since, at least looking at AbstractTransaction, it appears to simply be more of just storing the definition of the work to be executed in a class that has lots of convenient methods for repeating that piece of work in case of failure. Perhaps in other database implementations the submit() method may actually submit this work to the database without committing it? Or maybe this method is supposed to be used to stitch together many pieces of work with repeated calls to submit(), returning a Workload object that represents all the work submitted so far?
Thanks for helping me to understand this... On Sat, Nov 28, 2015 at 3:46 PM Dylan Millikin <[email protected]> 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 > > >
