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 >>
