Non-Blocking JDBC API

[Douglas Surber]

> On May 2, 2018, at 9:14 AM, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
> On May 1, 2018, at 8:02 PM, Rick Hillegas <rick.hillegas at gmail.com <mailto:rick.hillegas at gmail.com>> wrote:
>> Transaction management confuses me. What kinds of problems are solved by passing around a Transaction object rather than simply calling the commit()/rollback() methods on Connection? For those use-cases, why is it bad to pass around the Connection itself? Why is commitMaybeRollback() in the OperationGroup interface rather than in the Connection interface? What other OperationGroups are imagined besides Connection?
> 
> Douglas,  can you answer this for Rick.
> 

endTransactinoOperation() is in OperationGroup as it makes sense to have an endTransactionOperation as a member Operation of an OperationGroup. This is especially obvious if the OperationGroup is conditional. commitMaybeRollback is also in OperationGroup as it’s default implementation is possible in OperationGroup. commit() and rollback() are not in OperationGroup as their default implementations call transaction() which is only declared in Connection. transaction() is only in Connection because it is global, ie not restricted to a particular OperationGroup. It would be misleading to put transaction in OperationGroup.

I don’t expect the standard to define any other sub-types of OperationGroup other than Connection. OperationGroup itself will have concrete implementations in the various ADBA drivers. There are a number of use cases for OperationGroup independent of Connection.

The transaction model was difficult to arrive at but this one works. The problem that it has to address is timing. Conceptually there are two execution sequences that have to be considered: the app thread execution sequence that creates and submits the Operations and the async execution sequence that runs as the Operations are executed.

In the ideal case the app thread will create and submit all the Operations including Connection.closeOperation long before the Connection.connectOperation has returned. So before the first Operation is completed any transactionEndOperation must be submitted. (commit(), rollback(), and commitMaybeRollback all submit a transactionEndOperation.) Requiring the app to decide whether to commit or rollback before the first Operation completes is unreasonable. So the endTransactionOperation must be conditioned by something that the async thread can modify. (Modifying the endTransactionOperation itself doesn’t work for a variety of reasons.) That something is the Transaction. (Please suggest alternate names.) Passing around the Connection doesn’t work because the Connection.closeOperation has already been submitted. The async thread cannot submit an endTransactionOperation as it would be executed after the closeOperation.

The first cut at this model made the relationship between endTransactionOperation and the decision to commit or rollback implicit. That was exceedingly hard to describe and completely impossible to understand. Making endTransactionOperation take a Transaction argument, thus making the relationship between the endTransactionOperation and the decision to commit or rollback explicit made this much easier to describe and understand. I believe that you understand how to use Transaction. The questions you and others have asked are about what motivates it, not how to use it.

I don’t think commit() and rollback() are particularly useful and would be completely happy to remove them.

Douglas