No. The JDBC-ODBC Bridge does not support concurrent access from different threads. The JDBC-ODBC Bridge uses synchronized methods to serialize all of the calls that it makes to ODBC. Multi-threaded Java programs may use the Bridge, but they won't get the advantages of multi-threading.
If we are using PreparedStatement the execution time will be less. This is because PreparedStatement object contains SQL statement that has been precompiled. Thus, when the PreparedStatement is later executed, the DBMS does not have to recompile the SQL statement and prepared an execution plan - it simply runs the statement.
Quite often in database processing, we come across the situation wherein one transaction can change a value, and a second transaction can read this value before the original change has been committed or rolled back. This is known as a dirty read scenario because there is always the possibility that the first transaction may rollback the change, resulting in the second transaction having read an invalid value.
Five types of isolation levels are as follows:
If the application needs only committed records, then TRANSACTION_READ_COMMITED isolation is the good choice.
If the application needs to read a row exclusively till you finish your work, then TRANSACTION_REPEATABLE_READ is the best choice.
If the application needs to control all of the transaction problems (dirty read, phantom read and unrepeatable read), you can choose TRANSACTION_SERIALIZABLE for maximum safety.
If the application doesn’t have to deal with concurrent transactions, then the best choice is TRANSACTION_NONE to improve performance.
If the application is searching for records from the database then you can easily choose TRANSACTION_READ_UNCOMMITED because you need not worry about other programs that are inserting records at the same time.
The JDBC API has 3 Statements
1. Statement, 2. PreparedStatement, 3. CallableStatement.
The key features of these are as follows: