Missing important transaction parameters

[datiscum]

When testing various "select" statements, the test programme suddenly stopped and did not return. The problem was an open transaction in another database connection. Immediately after committing the open transaction, the test programme returned the corresponding values. When I looked for the problem in rsfbclient, I noticed that it only knows one parameter for the configuration of the transactions.

pub enum TrIsolationLevel { /// Transactions can't see alterations committed after they started Concurrency = ibase::isc_tpb_concurrency as u8, /// Table locking Concistency = ibase::isc_tpb_consistency as u8, /// Transactions can see alterations committed after they started ReadCommitted = ibase::isc_tpb_read_committed as u8,}

Here all other important transaction parameters are missing to solve exactly this problem.

https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref30/firebird-30-language-reference.html#fblangref30-transacs-settransac

Transaction Parameters

The main parameters of a transaction are: data access mode (READ WRITE, READ ONLY) lock resolution mode (WAIT, NO WAIT) with an optional LOCK TIMEOUT specification isolation level (READ COMMITTED, SNAPSHOT, SNAPSHOT TABLE STABILITY).

My standard in GUI applications for Firebird is: nowait read_committed rec_version

[datiscum]

I changed the following in connection.rs and my problem with the test application hanging was solved.

connection.rs let tpb = [ibase::isc_tpb_version3 as u8, ibase::isc_tpb_rec_version as u8 , ibase::isc_tpb_read_committed as u8,ibase::isc_tpb_nowait as u8];

In the database monitoring I could see the following: Your Transaction Parameter: Isolation Mode: read committed no record version Lock Timeout: Infinite wait

My Parameter: Isolation Mode: read committed record version Lock Timeout: No wait

[fernandobatels]

I will check this tonight. Anyway, do you can provide a code example of your program?

The problem was an open transaction in another database connection.

Was this second connection made by your process? Or by another program like flamerobin?

[datiscum]

I will check this tonight. Anyway, do you can provide a code example of your program?

I use the supplied "select.rs" example. Only read a few values from the DB with select.

The problem was an open transaction in another database connection.

Was this second connection made by your process? Or by another program like flamerobin?

flamerobin yes! I forgot to confirm the change in the table used by "select" and then the "select.rs" got stuck, which then pointed me to the problem.

I would like to be able to specify the transaction parameters that are to be used by default when connecting to the database. And in self-started transactions, the parameters can then also be passed again when needed.

[fernandobatels]

I will check this tonight.

The problem is real.

I would like to be able to specify the transaction parameters that are to be used by default when connecting to the database. And in self-started transactions, the parameters can then also be passed again when needed.

I will start the study to implement this feature. Maybe in a faw days it will be ready for testing.

[fernandobatels]

Version 0.21.0 released with transaction parameters support.