|Subject||Re: Are Deadlocks realy handled correct?|
> I know how to set the TransactionIsolation. But what I think is,Sorry, I do not understand you. Database (or database server) is
> that the only one who has the competence to act with Isolation-
> Levels is the database. I think JDBC in any way is just for hand-
responsible for concurrency control when multiple clients are
involved (i.e. checking if client can lock record, if transaction can
commit, etc.), and each client specifies transaction isolation it
needs depending on the application code. I do not know about other
database servers, but InterBase/Firebird does not allow you to
specify transaction isolation from within stored procedure, trigger
or simply in SQL statement (isql allows this, but this is command for
isql, not database server). However I would not be surprised if
Oracle provides such feature.
JDBC is client-side API, same as any other client-side API (for
example, Oracle Net8 interface). It is the responsibility of the
client to manage its transactions. Transaction isolation is part of
client transaction's parameters. Database server has no control on
client's parameters, it is responsible for maintaining database in
consistent state taking into account client's parameters (database,
transaction, statement, etc.).
> Following this, there musn't bee a difference in acting withTo certain extent. JDBC defines isolation levels and there should be
> different drivers!
no difference between different JDBC drivers using the same isolation
level. But specification does not prescribe what is the default
isolation level for driver. Therefore, if you do not explicitly set
isolation level, switching to another driver might provide you
For example, usually READ_COMMITTED is the default transaction
isolation, but in InterBase/Firebird default is something similar to
REPEATABLE_READ and READ_UNCOMMITTED is not supported at all.