Last Saturday at Trivadis Tech Event, I presented on Application Continuity, Transaction Guard … choose your degrees of freedom”.
What a strange title, you will be asking! What do Application Continuity (AC) and Transaction Guard (TG) have to do with freedom 😉
And why talk about Transaction Guard, isn’t that just a technology used by AC? Surely it’s not something you would care to implement – if the language you’re working with is Java?
Well, there are – in addition to the extensive, but not really easy to digest Oracle documentation – some very helpful resources (blog articles, presentations) on the net, but these mostly focus on infrastructural aspects: How does AC work with RAC, with Data Guard, with RAC One Node? What does the DBA have to do to enable AC (or TG)?
The demos are mostly designed to demonstrate that AC “just works”, in different environments. As the client code is not in focus, often the easiest way of implementing AC on the client is chosen: using Oracle Universal Connection Pool (UCP). (I’ve encountered one notable exception, which is Laurent Leturgez’ very interesting post on AC resource usage.)
However, in real life, much will depend on the developer teams: Are they comfortable with making the necessary modifications? Do they trust the technology? What if they, for whatever reasons, use their own connection pool, and so can’t use UCP?
In this presentation, the focus is on the developers’ part. How the code looks / might look, and what pitfalls there are – what errors you might see if you don’t do it right, and what they mean. This is for both AC and TG.
Let’s assume, however, that you’re VERY impatient and just want to know what the “main thing” is here 😉 … I’d say it’s about TG.
As of today, I’m not aware of any Java code on the web implementing TG that is NOT from Oracle documentation / whitepapers. Of course, as the topic is not easy and probably a bit “scary”, we are thankful for the example code Oracle provides. In Transaction Guard with Oracle Database 12c Oracle provide the following code example, which shows how it works:
Connection jdbcConnection = getConnection();
boolean isJobDone = false;
while(!isJobDone) {
try {
updateEmployeeSalaries(jdbcConnection);
isJobDone = true;
} catch (SQLRecoverableException recoverableException) {
try {
jdbcConnection.close();
} catch (Exception ex) {}
}
Connection newJDBCConnection = getConnection();
LogicalTransactionId ltxid = ((OracleConnection)jdbcConnection).getLogicalTransactionId();
isJobDone = getTransactionOutcome(newJDBCConnection, ltxid);
jdbcConnection = newJDBCConnection;
}
}
Basically we have a loop around our transaction. Normally that loop is left immediately. But in case we receive a recoverable exception, we get a new connection, obtain the Logical Transaction ID from the dead connection, and ask the database server for the transaction outcome for that LTXID. If the commit went through successfully, we’re done, otherwise we resubmit our transaction.
Now while this demonstrates how to do it, we do not want to clutter our code like this everywhere, do we? And fortunately, with Java 8, we don’t have to!
In Java 8, we have Functional Interfaces. Formally, a functional interface is an interface with exactly one explicitly declared abstract method. This abstract method can be implemented directly inline, using a lambda expression. That is, the lambda expression IS an implementation of the functional interface.
This allows us to separate transaction handling from the business methods, and get rid of the above loops. How?
On the one hand, this is how one business method could look:
private void updateSalaries(Connection conn) throws SQLException {
String query = "select empno, sal from tg.emp";
PreparedStatement stmt = conn.prepareStatement(query, ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
int oldsal = rs.getInt("sal");
int newsal = calculateNewValue(oldsal);
rs.updateInt("sal", newsal);
rs.updateRow();
}
rs.close();
stmt.close();
}
On the other, here we have a functional interface:
@FunctionalInterface
public interface Transaction {
public void execute(Connection connection) throws SQLException;
}
One implementation of a transaction can be a lambda expression that wraps the updateSalaries business method, like this: (conn -> updateSalaries(conn)):
TGTransactionProcessor tp = new TGTransactionProcessor(url, appUser, appPasswd);
if (tp.process(conn -> updateSalaries(conn))) {
logger.fine("Salaries updated.");
}
public boolean process(Transaction transaction) throws SQLException {
boolean done = false;
int tries = 0;
Connection conn = getConnection();
while (!done && tries <= MAXRETRIES) {
try {
transaction.execute(conn);
conn.commit();
conn.close();
done = true;
} catch (SQLRecoverableException e) {
try {
conn.close();
} catch (Exception ex) {
}
LogicalTransactionId ltxid = ((OracleConnection) conn).getLogicalTransactionId();
Connection newconn = getConnection();
setModule(newconn, moduleName);
done = isLTxIdCommitted(ltxid, newconn);
if (done) {
logger.info("Failed transaction had already been committed.");
} else {
logger.info("Replay of transaction neccessary.");
tries++;
conn = newconn;
}
}
}
return true;
}
So with Java 8 Functional Interfaces, we have an elegant way to separate business logic and transaction handling in general, and implement TG in Java, specifically.
So that’s the end of the “highlights of” section, for more information just have a look at the slides :-).
recurrent null 