Stabilize transactions support

[jclark]

Could potentially be split into two parts:

• local
• distributed

[lafernando]

Hi,

As brought up in #266, the transactions feature will be critical to Ballerina to be a production ready programming language. This is based on the soon to be released jBallerina 1.0. The 1.0 version generally gives the idea that the prominent features available and stable. Specially, Ballerina positioned as a network distributed programming language, database transactions can be considered something fundamental that should be there.

So is it possible to give this aspect more priority to improve the design (at least local transactions), validate its usage, and come to a point that, we can take it out of experimental status for jBallerina 1.0?. Or else, maybe we have to possibly think of a lower version label for the jBallerina release?.

Cheers,
Anjana.

[jclark]

There is now a proposal for this.

[jclark]

@mohanvive @gimantha My thinking on outstanding nits is as follows:

1. The CommitHandler and RollbackHandler types need to be isolated (it's not safe otherwise)
2. There should be a distinct error type transaction:Error for errors from commit (transaction:TransactionError is unnecessarily repetitive)
3. For a rollback statement without an expression within a retry-transaction-stmt, we have two choices
   • it's a compile-time error, or
   • it's allowed and no retry will happen (I think this would be slightly more useful, but I don't feel strongly)
4. whether an anonymous function is transactional should be inferred based on whether the function does anything which is allowed only for a transactional function (transactional is doing a different kind of thing from isolated, so inference should work differently)
5. RetryManager and RetriableError should go in lang.error (but with error:Retriable rather than error:RetriableError)

We can discuss further if you disagree with any of these.

[pcnfernando]

Ack on 1, 2 and 4.
Need some verification on point 3 and 5.

(3) The behavior as per the current implementation for rollback statement within a retry-transaction-stmt is to rollback without retrying. It should be an error return(fail e or return e) from the transaction for it to retry.
As per #267 (comment) I inferred that it should retry.
Therefore, we'll rollback and pass nil to shouldRetry() so that retrying is ignored for the rollback statement without an expression within a retry-transaction-stmt and retry for the other case.

(5) We moved RetryManager to lang.object and RetriableError as error:Retriable to lang.error as per the suggestion in #267 (comment). We will have to move back RetryManager to lang.error now.

[jclark]

@pcnfernando I was confused on (3): what you are doing sounds good.

But return e isn’t a failure, so it shouldn’t retry. From the proposal:

This means that failure of a check expression is no longer always equivalent to returning the error. In particular a transaction will be able to treat check-failure as different from return.

[jclark]

Please have a look at 7.22 and 7.23 in the spec to make sure we are in alignment.

[pcnfernando]

Ack. (3) should be corrected as:

It should be a failure outcome from the transaction for it to retry.

Furthermore, we'll be keeping the existing behavior for the rollback within a retry-transaction-stmt.

[pcnfernando]

Clarification on making CommitHandler and RollbackHandler types isolated (1).
When we make the handlers isolated, the functions passed for onCommit and onRollback needs to be isolated and the variables within the functions should abide according to isolated function type.

eg:

string ss = "";

@test:Config {
}
function testTrxHandlers() {
    ss = ss + "started";
    transactions:Info transInfo;
    var onRollbackFunc = isolated function(transactions:Info? info, error? cause, boolean willTry) {
        //ss = ss + " trxAborted";     # invalid access of mutable storage in an 'isolated' function
        io:println("trxAborted");
    };

    var onCommitFunc = isolated function(transactions:Info? info) {
        //ss = ss + " trxCommited";   # invalid access of mutable storage in an 'isolated' function
        io:println("trxCommited");
    };

    transaction {
        transInfo = transactions:info();
        transactions:onRollback(onRollbackFunc);
        transactions:onCommit(onCommitFunc);
        trxfunction();
        var commitRes = commit;
    }
    ss += " endTrx";
}

[jclark]

When we make the handlers isolated, the functions passed for onCommit and onRollback needs to be isolated and the variables within the functions should abide according to isolated function type.

Yes, that is the effect of making these types isolated.