tags:

views:

405

answers:

2

Hi All,

I am not very sure about the auto commit mode of java JDBC, I am making a connection whose auto commit mode is set to false. After that I fire a select query on database, which works fine, I am under impression that commit has to be called only for insert, update, delete statements.

Now do I need to commit the connection for Select query? If not will that table be locked for other transactions?

Thanks, Rohit.

+1  A: 

It depends on your isolation level. If you use READ COMMITTED, the SELECT only creates locks if you specify SELECT FOR UPDATE. If you use REPEATABLE READ or higher, every SELECT could create a lock (depends on your database model).

tangens
http://java.sun.com/j2se/1.3/docs/api/java/sql/Connection.html#TRANSACTION_REPEATABLE_READ - there is nothing about select statment that create lock. Lock is created by DML statments
cetnar
If you do a "SELECT FOR UPDATE" on an Oracle DB, a second transaction blocks (waits on a lock) if it does a "SELECT FOR UPDATE" on the same record.
tangens
@tangens I mean regular select. I've pointed in my response that select for update create lock in any case. In `REPEATABLE READ` isolation model regular select doesn't create a lock. Isolation modes adheres to uncommited changes and rules for select of data affected by this changes.
cetnar
A: 

I am not very sure about the auto commit mode of java JDBC, I am making a connection whose auto commit mode is set to false. After that I fire a select query on database, which works fine, I am under impression that commit has to be called only for insert, update, delete statements.

That's depends of your application. If there are simple updates, inserts, deletes you can leave autocommit=on. Generaly, it's recomended to off autocommit. That configuration gives you more flexibility and power in applicaiton. You can use complex transactions and you can decide when transaction begins and when ends.

Now do I need to commit the connection for Select query? If not will that table be locked for other transactions?

No, select statment doesn't begin transaction (insert, update, delete does) so there is no need to commit/rollback after select statment. There is one special case of select which lock selected rows and need transaction - with for update clause

cetnar
This is incorrect. All JDBC statements are **always** executed in transaction context, including SELECT.
ChssPly76
Are you sure? If select query will begin transaction it will block data for orther selects. Select can be run in existing transactions but don't begin new one.
cetnar
@cetnar - I'm positive. Any statement executed against the database (including SELECTs) is executed within transaction context. Any statement (excluding DDL in some cases) can run within existing transaction or new (separate) transaction after previous transaction (if any) has been committed / rolled back. See JDBC tutorial (http://java.sun.com/docs/books/tutorial/jdbc/basics/transactions.html) or spec for more details.
ChssPly76
@ChssPly- I try to be more precise. There are some kind of select statments that need commit or rollback (for update or dbLink selects). Implementations of Java Connection interface don't parse statments so after every statements is a commit. From database side if you commit a regular select statement nothing change, so in my opinion commit is unnecessary. Do you commit after selects in SQLPlus? The question was `Now do I need to commit the connection for Select query? If not will that table be locked for other transactions?` - my answers was no/no. If you will do commit nothing wrong happened
cetnar