Spring @Transactional read-only mode rollback behaviour
So as far as I understand, you are worried about the roll-back. In this case a readOnly
is a select statement
and usually there is nothing to roll-back from a read
. The only place where this is handy is when you read under a lock and when the transaction finishes you release that lock.
AFAIK readOnly
will set the flushmode to FlushMode.NEVER
and that is good and bad at the same time. Good, because there will no dirty checking, as described here. Bad because if you call a read/write transaction within a readOnly
transaction, the transaction will silently fail to commit because the session is not flushed. This is easily testable btw - and I hope things have not changed since I've tried this.
Then there is the pool of connections. I know that C3P0
's default policy is to rollback any uncommitted work. The flag to control this is autoCommitOnClose
.
Then there is this link about readOnly
and postgres
- which I have not worked with and can't really tell my opinion on.
Now to your point about Transaction rolled back because it has been marked as rollback-only
. For a readOnly
transaction there might be nothing to roll-back as I said before, so this really depends on how you chain your @Transactional
methods IMO.