>> Yes, maybe, I've also thought that. I would happily try to find this
>> bug. Even in FB 1.0 on Linux or in FB 1.0 in Windows, because ONE OF
>> THEM is buggy. But I'm not familiar with C/C++, even I don't know
>> where to start. Although it seems I'm not the only one who met this
>> problem, I'm afraid there is noone who is interested in debugging
>> this. Only Pavel wrote a mail, and even he told this is not a bug.

r> Unfortunatelly, we cannot force them to check this problem. I will
r> try to help you in this issue.

I don't want to force them, but what I made me sad is the first
reaction was this is not a bug. I don't want to say this: come on, what a
buggy software, I *do* really appreciate their work on this great
project. But I believe the behaviour of the RDBMS should not depend on
the operation system.

r> What I would do first would be the rebuild of one of the native
r> components from the source. What we need to, is to check what DPB and
r> TPB are provided there and make them the same in driver. I made some
r> changes in InterServer and the DPB they are using is very simple:

r> isc_dpb_user_name="SYSDBA"
r> isc_dpb_password="masterkey"
r> isc_dpb_lc_ctype="NONE"

r> I also made that changes to my sources of type 4 driver. I had no
r> time to check the TPB of InterClient in case of
r> TRANSACTION_READ_COMMITTED isolation.

InterClient, by default, uses TRANSACTION_SERIALIZABLE which equals to
TRANSACTION_SNAPSHOT, according to InterClient.

be default Interserver initializes the TPB like this:
*(readWriteToggle_ = parameterBlock_.next()) = isc_tpb_write;
*(autoCommitToggle_ = parameterBlock_.next()) = isc_tpb_write;
*(isolation1Toggle_ = parameterBlock_.next()) = isc_tpb_concurrency;
*(isolation2Toggle_ = parameterBlock_.next()) = isc_tpb_concurrency;
*(lockResolutionToggle_ = parameterBlock_.next()) = isc_tpb_nowait;

When you change to READ_COMMITED this is what happens:

*isolation1Toggle_ = isc_tpb_read_committed;
*isolation2Toggle_ = isc_tpb_read_committed;

So with a 99% of probability :) IC starts with the following TPB when
opening a new transaction:

readWriteToggle = isc_tpb_write;
autoCommitToggle = isc_tpb_write;
isolation1Toggle_ = isc_tpb_read_committed;
isolation2Toggle_ = isc_tpb_read_committed;
lockResolutionToggle = isc_tpb_nowait;

r> And we have to check what is used by FIBPlus or IBX. After having
r> exact DPB/TPB settings we can try to create a unit test for native
r> component using only API calls. The same we should do in Java. And if
r> the bug is there, post it to bug tracker.

FIBPlus is not opensource. Moreover FIBPlus comes from IBX, since
there a few open-source files that are almost the same IBX. I have
debugged IBX at its lowest level, my result is:

IBX uses dpb_user_name and dpb_password only.

By default IBX does not start transactions with isc_start_transaction,
but with isc_start_multiple(). The reason may be that transaction is a
separate component in Delphi and it can be assigned to multiple
databases. It does pass only one TPB, because I used only one
database, but the TPB was EMPTY. It did not contain any parameter at
all. IBX does not allow the change isolation level, although you may
pass any isc_tpb parameter to the transaction.

I'm almost sure also FIBPlus does the same. I'll contact the author of
IBObjects, which is not free, but he is going to provide the source
for open-source projects :)

ZeosLIB uses *isc_tpb_nowait* always and

itConsistency:
begin
TempParams.Add(isc_tpb_consistency, '');
end;
itConcurrency :
begin
TempParams.Add(isc_tpb_concurrency, '');
end;
itReadCommitted:
begin
TempParams.Add(isc_tpb_read_committed, '');
TempParams.Add(isc_tpb_no_rec_version, '');
end;
itReadCommittedRec:
begin
TempParams.Add(isc_tpb_read_committed, '');
TempParams.Add(isc_tpb_rec_version, '');
end;

By default ZeosLIB uses ONLY isc_tpb_nowait. If you want to use
readcommited, etc.. you should set that, e.g. read commited is not
used by default.

ZeosLIB uses isc_start_transaction, but immediately after calling
this, it also calls isc_start_multiple as well (unlike IBX it calls
start_multiple always with only for one database, ZeosLIB does not
allow you to assign a transaction to more than one database).
The comment says this:

//problem with GDS32.dll ---> ib6
//ajouter par fourat-----> isc_start_multiple

I've translated it on google, it say "added by fourat", but who knows?
I don't speak French at all... maybe this is even not in French.

Roman, if you "speak" Delphi/Pascal, I'll send any parts from these
sources, please tell if there anything else I can do for you.

r> This is quite an amount of work. Can you do this native code research
r> (I do not have Delphi/IBX). I would do the InterClient check.

>> Maybe not a bug of the Linux version, but in this case this is a
>> bug a Windows version.
>>
>> I don't know if sending a bug report helps or not, but as you told I
>> even can't decide if it is the bug of FB-Linux of FB-Windows.

r> Let's try to get some more results. BTW, there was similar posting in
r> InterClient newsgroup. I will check the replies.

r> Regards,
r> Roman

Summary: these interfaces for Delphi is not so strict like Java when
starting a new transaction. Probably this is the reason why we have
this only in Java never with Delphi. Most of GUI tools were written in
Delphi, that's why they work well. Probably if these Delphi softwares
were using same TPB as Java they would have problems when managing a
FB install on Linux. I would not be surprised if isql were not use
that TPB that you use.

I've not found yet where type 4 driver sets isc_tpb_*, but maybe we
could do a test with no tpb at all and with isc_tpb_nowait parameter only.

One more interesting thing:
I've created an application in Delphi with IBX.

I set the following parameters for the IBTransaction component:
(this is what you wrote on IB-Devel, isn't it?)

isc_tpb_write
isc_tpb_concurrency
isc_tpb_wait

I've been connection to the database from my home computer to the
database on Linux using TCP.

The Delphi program produced absolutely the same results as my Java
program, so there was absolutely no java, it's enough to set these
three parameters for a transaction to:

1. have a deadlock when connection to a database using isql
2. not to update the record commited in isql.

Now what? Shell I send my Delphi program as a bug report? Is it a bug
at all? Are these parameters correct? Have not I missed anything?


Best wishes,
Daniel