Subject Re: [Firebird-Java] Re: Are Deadlocks realy handled correct?
Author Helen Borrie
At 03:37 PM 18-05-02 +0200, Hans Georg Frey wrote:

> > > > Be sure to set
> > > > transaction isolation explicitly (our driver and InterClient might
> > > > have different default values).
> > >
> > > Ooops! I thought the only one beeing responsible for isolation-level
> > > ist the database.
> >
> > In JDBC you set transaction using
> > java.sql.Connection.setTransactionIsolation(int) method.
>I know how to set the TransactionIsolation. But what I think 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-over!
>Following this, there musn't bee a difference in acting with
>different drivers!

oooh no! the client is responsible for setting the transaction isolation -
not the database, not the driver. Some drivers have a DEFAULT transaction
isolation, which is sometimes (but not always) SNAPSHOT (REPEATABLE READ) -
the default isolation applied by the isql command-line client. This level
is sometimes nicknamed "concurrency" (and, in the enumerated
TransactionIsolation types in Delphi, Kylix and C++Builder it is
tiConcurrency). So it is necessary for you, as the application developer,
to know which settings are default for the particular driver you are using.

For interactive work, a transaction isolation of READ COMMITTED is usually
better. Native IB Objects, for example, defaults all transactions to this
level (tiCommitted).

Being able to control the isolation level of transactions is the essence of
the power of a client/server database. Drivers surface to your application
environment the Transaction Parameter Block (TPB), which is the API
structure in which isolation level, locking behaviour and (in the case of
READ COMMITTED) the mode of record version control are set. The TPB has
some other parameters, less often used, which can also affect isolation.

As for handling of deadlocks, that is the responsibility of your client
application. It is a design decision for you to recognise and handle
deadlocks. You shouldn't *fear* a deadlock - it is a sign that the
database is doing its job properly.


All for Open and Open for All
Firebird Open SQL Database · ·