Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Series of transactions are repeated automatically after system abnormal shutdown [CORE4732] #5038

Open
firebird-automations opened this issue Apr 3, 2015 · 5 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Dmitry S. Gostev (dmitrygostev)

Attachments:
GOODS.fdb

This bug existed since version 1.0 and went through the versions to 2.5.3

The situation is as follows:
1. Empty database with some tables, generators created.
2. The user starts to work, opens transaction, inserts a row into table A, the transaction is committed
3. Then he makes a transaction with a query like this:
UPDATE <TABLE B> SET <INTEGER FIELD>=<INTEGER FIELD>+<some value> WHERE <ID field>=some value
The transaction is commited after each UPDATE query
4, The he makes a transaction with a query:
INSERT INTO <TABLE C> ...
transaction is commited
5. The steps 3,4 are repeated for <n> times with dirrerent data.
6. The user disconnects from the base or permits another query INSERT INTO <TABLE A>.

Then the user works with the database for a week, for a month or a year (the period doesnot matter), he can add new fileds, can make changes to <INTEGER FIELD> in the <TABLE B>. Then occurs an abnormal shutdown of the computer (for example, electricity is cut off).
When the power is restored and the user connects to the database, the user finds out that the values of the <INTEGER FIELD> of the <TABLE B> are mistakenly increased by the <some value>, like the Firebird 'repeated' all the transactions made in the step 3.
No matter how many times the user made steps 2-5, the Firebird repeats only the first since the database creation sequence of the 'step 3' transactions.
If needed, the database and the transaction/table detail can be supplied.

@firebird-automations
Copy link
Collaborator Author

Commented by: Dmitry S. Gostev (dmitrygostev)

database after system shutdown: the fields AMOUNT in the table GOODS are wrongly changed.
The values of the wrong changes can be seen in the table INV_OPERAT:
SELECT GOOD_ID,QUANT FROM INV_OPERAT WHERE INV_ID=1

@firebird-automations
Copy link
Collaborator Author

Modified by: Dmitry S. Gostev (dmitrygostev)

Attachment: GOODS.fdb [ 12692 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

@dmitry

Your description is unclear, please elaborate on :
When the power is restored ... like the Firebird 'repeated' all the transactions made in the step 3.

Are you aware that *committing* the transaction means that the changes are "crystalized"?

This means that only incomplete transactions would be lost as a result of adnormal shutdown.

As such, what you seem to describe is the expected operation -- when the database is opened after the shutdown, the last committed values are present.

@firebird-automations
Copy link
Collaborator Author

Commented by: Dmitry S. Gostev (dmitrygostev)

I do not mean that changes are crystalized or something like that.
I meant that I commit series of transactions with queries like

UPDATE <TABLE B> SET <INTEGER FIELD>=<INTEGER FIELD>+<some value> WHERE <ID field>=some value

Then work with the database, create thousands or millions or billions transactions that affect <TABLE B> or not affect it, that affect values of <ID field> in this table or not affect, disconnect from the database, connect to the database thousand times, work for a week, maybe for a month or for ten years. And it's OK, before I abnormally turn the computer power off. Then the power comes and I connect to the database, the values in the <TABLE B> are wrongly changed by the database server, just like it repeated these series of transactions.

@firebird-automations
Copy link
Collaborator Author

Commented by: Dmitry S. Gostev (dmitrygostev)

During 2 months after I reported this issue, three or four databases screwed up again.
Still the bug is marked as 'unassigned'. Is this tracker working or not?
The bug is easily repeated, I can provide developers with archive databases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant