Explicitly release rolled-back database savepoints during (long-running) transaction [SPR-12228]

[spring-projects-issues]

Roman Konoval opened SPR-12228 and commented

When rollback of nested transaction happens savepoint is cleared in AbstractTransactionStatus and ROLLBACK TO SAVEPOINT is executed against database but savepoint in not released in database. This leads to leak of savepoint.
If very few nested transactions fail in one outer transaction this may be unnoticed as savepoints are release on outer transaction end. But when large number of nested transactions are rolled back this is visible. On idle postgres 9.1.13 with default settings about 10k rollbacks on nested transaction exhaust memory dedicated for storing locks.

---

Affects: 3.2.11, 4.0.7, 4.1 GA

[spring-projects-issues]

Juergen Hoeller commented

Good point - our rollbackToSavepoint javadoc even suggested such behavior. As of 4.1.1, each JDBC savepoint gets explicitly released after a rollback to that savepoint now.

Please give the upcoming 4.1.1 snapshot a try and let me know whether it works for you... This is also scheduled for a backport to 4.0.8 and 3.2.12 later this week.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Discussion about the details of the fix here: 9c8f7d9#commitcomment-7873493

Point taken, programmatic use of SavepointManager might want to roll back to the savepoint several times, despite our rollbackToSavepoint javadoc suggesting an automatic release after rollback. It might be better to fix the javadoc, i.e. remove the comment about automatic release, and just fix this issue here in AbstractTransactionStatus for managed transaction savepoints.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I've revised the fix to apply at the AbstractTransactionStatus level now, with a programmatic rollbackToSavepoint call not releasing the savepoint - and the SavepointManager javadoc now saying so.

As for the OpenJPA case, the releaseSavepoint implementation there now defensively catches any exceptions thrown, which is what the SavepointManager javadoc suggests anyway.

Since this isn't a local change to JDBC savepoint handling anymore but rather a significant change in the SavepointManager invocation algorithm for managed nested transactions now, going through an abstraction where we don't control all implementations, I'm reducing the applicability of this fix to 4.1.1 only.

Juergen