Jaybird and wait on locks

[Roberto Vieweg]

How can I set my JDBC connections to use "wait on locks" instead of "raise deadlock exception" ?  

[Mark Rotteveel]

On 11-08-2020 20:26, Roberto Vieweg wrote:
> How can I set my JDBC connections to use "wait on locks" instead of
> "raise deadlock exception" ?

The default transaction definition of Jaybird waits on locks, so I guess
you mean you want READ COMMITTED NO RECORD_VERSION behaviour instead of
READ COMMITTED RECORD_VERSION that Jaybird uses by default.

You can redefine the definition of a transaction in Jaybird by
specifying the TPB items of the isolation level. For example:

jdbc:firebirdsql://localhost/database.fdb?TRANSACTION_READ_COMMITTED=read_committed,no_rec_version,write,wait

or (using the full TPB item names)

jdbc:firebirdsql://localhost/database.fdb?TRANSACTION_READ_COMMITTED=isc_tpb_read_committed,isc_tpb_no_rec_version,isc_tpb_write,isc_tpb_wait

See also

1)
https://firebirdsql.github.io/jaybird-manual/jaybird_manual.html#transactions-isolation-levels
2)
https://firebirdsql.github.io/jaybird-manual/jaybird_manual.html#connectionproperties-isolation-levels

Mark
--
Mark Rotteveel

[Roberto Vieweg]

Even in Jaybird 3.0.1, is the default "wait on locks" ?

Because I'm getting this without setting any connection properties:

org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544336. deadlock

update conflicts with concurrent update

concurrent transaction number is 5608174

[Mark Rotteveel]

On 11-08-2020 22:17, Roberto Vieweg wrote:
> Even in Jaybird 3.0.1, is the default "wait on locks" ?
>
> Because I'm getting this without setting any connection properties:
>
> org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544336. deadlock
> update conflicts with concurrent update
> concurrent transaction number is 5608174

Yes, it has been the default since before Jaybird 2.2, likely always.

An update conflict like this can occur if you're attempting to update a
record that was modified and committed by another transaction and that
transaction was started before your transaction and committed after your
transaction started. And that is assuming you're using read committed
and not another isolation level.

For a better answer, I'd need a reproducible example.

Mark
--
Mark Rotteveel