Subject | Re: Transaction and concurrent updates |
---|---|
Author | Roman Rokytskyy |
Post date | 2004-04-17T10:49:01Z |
Hi,
that READ COMMITTED RECORD_VERSION (default isolation level for the
driver) deviates from the ANSI/SQL READ COMMITTED isolation level, so
that transation can see and *modify* committed changes from other
transactions. This seems to be missing from IB 6.0 documentation set,
but also seems to be known fact in FB community (I found explanations
at http://www.ibase.ru/devinfo/ibxtrans.htm, that's in Russian, but I
suspect that there must be some documentation in English too).
Default isolation level of the server corresponds driver's REPEATABLE
READ, and if you modify tx isolation in that Java example, you get the
desired behavior.
Best regards,
Roman Rokytskyy
> The second transaction reports a deadlock, as ISQL does, if I setRecently I had some time to research this issue deeper. It turned out
> the transaction parameters to empty array. What are the default
> transaction parameters?
>
> int[] trnPars = {};
> conn1.setTransactionParameters(
> Connection.TRANSACTION_READ_COMMITTED, trnPars);
> conn2.setTransactionParameters(
> Connection.TRANSACTION_READ_COMMITTED, trnPars);
that READ COMMITTED RECORD_VERSION (default isolation level for the
driver) deviates from the ANSI/SQL READ COMMITTED isolation level, so
that transation can see and *modify* committed changes from other
transactions. This seems to be missing from IB 6.0 documentation set,
but also seems to be known fact in FB community (I found explanations
at http://www.ibase.ru/devinfo/ibxtrans.htm, that's in Russian, but I
suspect that there must be some documentation in English too).
Default isolation level of the server corresponds driver's REPEATABLE
READ, and if you modify tx isolation in that Java example, you get the
desired behavior.
Best regards,
Roman Rokytskyy