Search code examples
javaspringspring-datarollbacktransactional

Spring @Transactional is consistantly rolling back transaction upon exception

Alrighty folks. I've read quite a bit of docs. And at my wits end on why this is happening.

Like many of the other people, we have a service interfacing with a oracle db. This is a pretty standard setup

@Service
public class DaoService {

    private JdbcTemplate jdbcTemplate;

    private SimpleJdbcInsert insertA;
    private SimpleJdbcInsert insertB;
    private SimpleJdbcInsert insertC;

    @Autowired
    public Dao(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
        // Assume all Inserts are initialized
    }

    @Transactional(rollbackFor = Exception.class)
    public void insertStuff(Stuff stuff) {
         insertA.execute(stuff.A);
         // Suppose a connection failed here
         insertB.executeBatch(stuff.B);
         insertC.executeBatch(stuff.C);
}

Now here lies our issue. For 99% of all rollbacks they are a-ok.

When a connection gets closed for unknown reasons is where our problems occur. The exception message being

 TransactionSystemException: Could not roll back JDBC transaction;
     nested exception is java.sql.SQLException: "The connection is closed"

See, it tries to rollback as it's supposed to. But the issue is that stuffA lingers in the DB will stuffB and stuffC is not. This happens only like 1% of the time. (aka, sometimes despite the rollback failure, no 'stuff' will be in the DB.

Am I understanding something wrong? I thought spring only commits at the end of a successful transaction? Anyone have an idea on how I can stop these partial commits despite making in @Transactional?

p.s. for what it's worth. autocommit is defaulted to being on. However I read that it's not taken into consideration when something is @Transactional

Solution

  • From the Database JDBC Developer's Guide:

    If the auto-commit mode is disabled and you close the connection without explicitly committing or rolling back your last changes, then an implicit COMMIT operation is run.

    Maybe this is the case you are running into.