Hello Roman,

Wednesday, November 13, 2002, 12:36:16 AM, you wrote:

> Nickolay,

>> "serializable=concurrency",
>> "repeatable_read=consistency",
>> "read_commited=read_commited+rec_version+nowait"

> Why "nowait" is good here? Right now it is "wait".

Because it you have an environment where transactions are usually
committed (this is common) wait behavior may seem weird for you.
Transaction that have an update collision with another uncommited
transaction wait until that transaction finishes instead of failing
immediately. And there should be the same bug I fixed in
no_rec_version+wait mode. I you have more than two transactions having
an update conflict on the same set of rows n or n-1 transactions are
doomed to deadlock after waiting. Immediate failure should be better
in most cases.

Currently wait behavior is close to correct only for
read_committed+no_rec_version+wait mode in FB1.5 Alpha 3+.
I analyzed that code and fixed waiting bugs there.

>> Should I take care of this issue or you or Roman will handle it ?
>>
>> BTW, this would be good default mapping because consistency
>> isolation is based on table locking and is actually a bit weaker
>> (have more anomalies) than concurrency mode (but its still confirms
>> to Java SERIALIZABLE mode specification). Consistency is VERY
>> rarely used.

> Can you explain why consistency is weaker than concurrency?

concurrency makes a consistent snapshot of data at the beginning
of transaction. All changes made by other transactions are
invisible for concurrency mode transaction. Modification raises
deadlock exception if record to be modified was modified by another
transaction. There are essentially no anomalies except some VERY
warped like Ann mentioned earlier. Concurrency mode is very good for
long-running mostly read-only tasks that need to have consistent
data - like report-building.

You may get consistent results in consistency mode only if you lock
all tables you intend to use at the beginning of transaction. It is not
very JDBC compliant to enlist tables you intend to use in transaction
parameters.Does Jaybird support this ? But even in this case engine
does not guaranty that all tables will be locked at the same time.
It means that data in one table may be inconsistent with data in
another because they were locked at different point of time. I can
create some simple test cases that demonstrate select inconsistency
in this mode. And as you can understand table locking makes fatal
impact on update concurrency. You can easily kill the server by
selecting some records in consistency mode transaction and leaving
transaction uncommited for some time. This is a security issue in
fact.

> Best regards,
> Roman Rokytskyy

--
Best regards,
Nickolay mailto:skidder@...