What happens when JDBC AutoCommit is False and explicit Transaction boundaries aren't set

Question

Consider that a Java application is opening JDBC Connections to Postgres, with AutoCommit set to false.

On such JDBC Connections, if we execute SQL SELECT commands, then what happens to transaction boundaries? Are there any Implied Transaction boundaries even though AutoCommit is off?

Answer 1

Auto commit will not have any effect since you are only firing selects.

The default transaction isolation level will come into play for select clauses - for postgres it is set to READ_COMMITTED. From the docs :

Read Committed is the default isolation level in PostgreSQL. When a transaction uses this isolation level, a SELECT query (without a FOR UPDATE/SHARE clause) sees only data committed before the query began; it never sees either uncommitted data or changes committed during query execution by concurrent transactions.

Answer 2

6ton's right and that answer should be accepted. I just want to elaborate a little.

Your application will leave idle open transactions. This can prevent some cleanup work because PostgreSQL cannot mark the transaction as conclusively committed or rolled back. It doesn't matter much if you don't do any write operations (as no transaction ID is assigned) but should still be avoided.

If you SELECT a function that has side effects, those side effects won't be committed and will be lost when you disconnect.

If you're using SERIALIZABLE isolation due to configuration, a DB setting or a user default, you'll see data from the snapshot taken at the first SELECT . You'll also have database performance problems due to bloat caused by inability to VACUUM away old rows. This doesn't happen in READ COMMITTED isolation.

You really should do it properly and either autocommit or use explicit transaction demarcation.