From what I can tell, when a CMT bean times out (at least in the case of 3.2.6 and Stateless Session Beans), the transaction is simply marked as setRollbackOnly, but no exception is explicitly thrown. This leads to a situation where the bean can return data but the data is not consistant with the database. Here is a trivial example of a method in a CMT method in a SLSB:

public String getValue() throws Exception {
...
PreparedStatement statement1 = connection.prepareStatement("update tx_test set value=value+1 where id=12");
statement1.execute();
statement1.close();

PreparedStatement statement2 = connection.prepareStatement("select value from tx_test where id=12");
ResultSet rs = statement2.executeQuery();
String value=null;
if (rs.next()) {
value = Integer.toString(rs.getInt("VALUE"));
}
rs.close();
statement2.close();
connection.close();

... Do something else that takes some time ...

return value;
}

In this case, if the JBoss transaction times out while doing something else, the method will return properly with a bogus value as the transaction will never commit.

Obviously you can add a:
if (ctx.getRollbackOnly()) throw Exception()

as the last line before returning. However, the possibility still exists that the transaction will time out after the bean code is finished, but before the transaction is commited.

Regardless of the timing between the transaction time limit and the rest of the code, transaction timeouts will occur due to database locks, backups etc.

This seems like a major hole in the CMT design and I have rarely seen the rollback check in practice. Can anyone suggest a better way to handle this situation?