| Key: |
CORE-4014
|
| Type: |
Bug
|
| Status: |
Open
|
| Priority: |
Critical
|
| Assignee: |
Unassigned
|
| Reporter: |
Luis Lince
|
| Votes: |
0
|
| Watchers: |
1
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
By accessing remotely firebird with an open transaction and create a record, if you lose your Internet connection suddenly, to connect again, attempting to create the record again, it stays locked in the frozen state, I guess waiting for the conclusion the last transaction that was in the air, the problem is there is no way to conclude the transaction, does not even appear in the list of transactions in limbo (gfix-list), this because one of the fields must be unique.
The transaction have this options:
isc_tpb_version3
isc_tpb_write
isc_tpb_read_committed
isc_tpb_rec_version
isc_tpb_wait
|
|
Description
|
By accessing remotely firebird with an open transaction and create a record, if you lose your Internet connection suddenly, to connect again, attempting to create the record again, it stays locked in the frozen state, I guess waiting for the conclusion the last transaction that was in the air, the problem is there is no way to conclude the transaction, does not even appear in the list of transactions in limbo (gfix-list), this because one of the fields must be unique.
The transaction have this options:
isc_tpb_version3
isc_tpb_write
isc_tpb_read_committed
isc_tpb_rec_version
isc_tpb_wait |
Show » |
made changes - 18/Dec/12 05:52 PM
| Field |
Original Value |
New Value |
|
Security
|
Developers
[ 10012
]
|
|
|
When you create a record with a field that must be unique, in an open transaction, if connection is lost suddenly, you can not create the same record, until after some time.
That said, you may decrease the "freeze" time down to the specified amount, via changing either the system TCP keepalive setting (2 hours by default) or DummyPacketInterval setting in firebird.conf (disabled by default).
I don't see it as a bug, sorry.