The error above is the cause of improper transaction control, which can be written as follows.
Improper writing 1:
Connection OPEN.
Try {
Try {
Database operation A.
} Catch (Exception e) {
The log. The error (” do something “);
}
Database operation B. // The above error may occur during this data operation.
The transaction commits commit.
} Catch (Exception ex) {
Transaction rollback rollback.
} the finally {
Close the connection.
}
Improper writing method 2:
Connection OPEN.
Try {
Database operation A.
Database operation B.
The transaction commits commit.
} Catch (Exception ex) {
Database operation C. // The above error may occur during this data operation.
The transaction commits commit.
} the finally {
Close the connection.
}
In a Postgres database, if there is an error in a database operation in the same transaction, all subsequent databases in that transaction will fail.
If there is an error in database operation A, the same database operation B will report an error when it is executed. If there is an error in database operation A or database operation B, the same database operation C will report an error.
To avoid errors, someone is using the re-open method, which in effect throws away all previous operations (not in the case of auto-commit) and adds overhead by re-opening, which is not recommended.
Depending on the cause of the error, we can treat the processing before the possible error as a transaction. The processing after the error is then treated as a transaction, depending on the specific logic. That way you can avoid making mistakes.
In this way, we can change the improper 1 to
Try {
Database operation A.
} Catch (Exception e) {
Transaction rollback or commit;
The log. The error (” do something “);
}
Database operation B.
In this way we can change the improper notation 2 to
} Catch (Exception ex) {
Transaction rollback or commit;
Database operation C.
The transaction commits commit.
} the finally {
Close the connection.
}


