Subject | (Jim, Ann) Firebird tx isolation levels |
---|---|
Author | David Jencks |
Post date | 2002-09-22T12:05:49Z |
(Originally asked Sept 8 on firebird-dev)
Hi,
Currently the java driver maps jdbc tx isolation levels to firebird like
this:
TRANSACTION_SERIALIZABLE <--> isc_tpb_consistency + isc_tpb_wait
TRANSACTION_REPEATABLE_READ <--> isc_tpb_concurrency + isc_tpb_wait
TRANSACTION_READ_COMMITTED <--> isc_tpb_read_committed +
isc_tpb_rec_version + isc_tpb_wait
TRANSACTION_READ_UNCOMMITTED <--> isc_tpb_read_committed +
isc_tpb_rec_version + isc_tpb_wait
Apparently interclient mapped both TRANSACTION_SERIALIZABLE and
TRANSACTION_REPEATABLE_READ to isc_tpb_concurrency (I'm not sure about the
isc_tpb_wait).
Nickolay Samofatov thinks (see bug [ 575397 ] SERIALIZABLE is not
isc_tpb_consistency) that this is wrong and that our driver should emulate
interclient and map TRANSACTION_SERIALIZABLE and
TRANSACTION_REPEATABLE_READ to isc_tpb_concurrency + isc_tpb_wait.
I think that there is no way to have a completely satisfactory mapping of
the jdbc isolation levels into the firebird isolation levels, since as far
as I can tell the meanings have only some overlap. Therefore I think this
mapping should be based on what is most useful for the most users (which,
of course, I think the current mapping supplies).
I'd like some other opinions about this. I think that
1. isc_tpb_concurrency does have some update anomalies that mean that it
really shouldn't be labelled serializable
2. isc_tpb_consistency is stronger isolation than isc_tpb_concurrency
and
3. it is most useful for users of the driver to have more choices, so
mapping 2 jdbc levels to one firebird level will reduce the usefulness of
the driver. (we already map read uncommitted onto read committed!)
Please comment.
Thanks!
david jencks
Hi,
Currently the java driver maps jdbc tx isolation levels to firebird like
this:
TRANSACTION_SERIALIZABLE <--> isc_tpb_consistency + isc_tpb_wait
TRANSACTION_REPEATABLE_READ <--> isc_tpb_concurrency + isc_tpb_wait
TRANSACTION_READ_COMMITTED <--> isc_tpb_read_committed +
isc_tpb_rec_version + isc_tpb_wait
TRANSACTION_READ_UNCOMMITTED <--> isc_tpb_read_committed +
isc_tpb_rec_version + isc_tpb_wait
Apparently interclient mapped both TRANSACTION_SERIALIZABLE and
TRANSACTION_REPEATABLE_READ to isc_tpb_concurrency (I'm not sure about the
isc_tpb_wait).
Nickolay Samofatov thinks (see bug [ 575397 ] SERIALIZABLE is not
isc_tpb_consistency) that this is wrong and that our driver should emulate
interclient and map TRANSACTION_SERIALIZABLE and
TRANSACTION_REPEATABLE_READ to isc_tpb_concurrency + isc_tpb_wait.
I think that there is no way to have a completely satisfactory mapping of
the jdbc isolation levels into the firebird isolation levels, since as far
as I can tell the meanings have only some overlap. Therefore I think this
mapping should be based on what is most useful for the most users (which,
of course, I think the current mapping supplies).
I'd like some other opinions about this. I think that
1. isc_tpb_concurrency does have some update anomalies that mean that it
really shouldn't be labelled serializable
2. isc_tpb_consistency is stronger isolation than isc_tpb_concurrency
and
3. it is most useful for users of the driver to have more choices, so
mapping 2 jdbc levels to one firebird level will reduce the usefulness of
the driver. (we already map read uncommitted onto read committed!)
Please comment.
Thanks!
david jencks