Issue Details (XML | Word | Printable)

Key: CORE-4014
Type: Bug Bug
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Luis Lince
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Firebird Core

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.

Created: 18/Dec/12 05:25 PM   Updated: 20/Apr/20 04:53 PM
Component/s: API / Client Library
Affects Version/s: 2.1.5
Fix Version/s: None


 Description  « Hide
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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 18/Dec/12 05:52 PM
The former transaction is still considered active, this is why you cannot touch the same record again. That transaction will be rolled back as soon as the engine sees that the client connection is lost, thus allowing further actions with the same records. But the TCP/IP stack does not report a broken connection immediately, hence the issue.

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.

Luis Lince added a comment - 18/Dec/12 06:45 PM
Any suggestions for DummyPacketInterval, in Windows Server 2008. What might be the consequences of activating this feature (more traffic)?
Thanks

Dmitry Yemanov added a comment - 18/Dec/12 07:04 PM
It's just one TCP packet sent per the specified interval to the every idle client.
I'd suggest to move further discussions to the support list, the tracker is a wrong place for them.