Insert into t1 values (f1, f2) (v1, v2); 
The update t2 set f3=f3 + 1 where pk=id; 

Insert into the t1 table a detail record, at the same time the t2 in the table count field f3 1, 2 a DML statements in the same transaction execution,
In the machine test environment
everything is all rightRelease to production environment, access to more concentrated, there will be a number in the t1 table is larger than the count in the t2 table
Please help to analyze, this is the reason why the operation, thank you!

CodePudding user response:

There will be a number in the t1 table than t2 in the table count

This is supposed to be some not updated procedures section t2;

Might as well build a trigger in two tables, is used to record, and see what kind of data, only wrote not updated t1 and t2.

CodePudding user response:

Insert into t1 values (f1, f2) 1 (v1, v2);
2 the update t2 set f3=f3 + 1 where pk=id;

Article 2 the "pk=id" in the update condition does not meet this situation into account??

CodePudding user response:

The system as a whole, only this place has such a logic operation,
T1 and t2 are the main foreign key relationships, so pk="id" conditions are established for certain,

CodePudding user response:

May have access to more concentrated when you least expect them to lag, since the update operation depends on the insert operation, why not directly into the trigger?

CodePudding user response:

Suggest to switch to trigger

CodePudding user response:

May be a transaction 1 is not over yet, the same ID and INSERT T1 and UPDATE T2, the transaction will be waiting for the end of the transaction 1, 2
Transaction 1 submitted, transaction 2 will execute INSERT and UPDATE, and submit,
The logic seems to be no problem, but the INSERT is performed twice, UPDATE the F3 + 1 behind the F3 possible values are the same, if so, will lead to less than T1 T2,

To switch to trigger!

CodePudding user response:

Increase in the t1 table a similar PK field, compared with t2 synchronization again see the results

CodePudding user response:

Submit it using transaction mechanism, most languages support data transaction mechanism, what you are using a programming language called

Can consider to use select for update nowait way records to lock up first, and then perform the operation, finally commit releases the lock

CodePudding user response:

Id from its color in PLSQL, seemed like a keyword, estimates that you this problem could be related to it