In normal database programming, we encountered errors from time to time: Current Transaction is aborted, commands ignored until the end of transaction BlockP. How to solve it?We usually look it up on the Internet. If you’re a little bit better at English you can tell from the error message that there’s probably something wrong there. But if the experience is not very rich, or the Internet to find more convenient. The most basic error message can see from the official documentation (http://www.postgresql.org/docs/8.4/interactive/errcodes-appendix.html).
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.
}
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.
}
Read More:
- [Java] spring transaction control configuration error, application- persstence.xml Transaction manager report red in file
- Springboot + mybatis plus transaction management
- The COMMIT TRANSACTION request has no corresponding BEGIN
- SQLServerException: The server failed to resume the transaction. Desc:ab00000002
- Lock wait timeout exceeded — transaction and index
- MySQL error 1205 (HY000): lock wait timeout exceeded; try restarting transaction
- The transaction log for database ‘xxxx’ is full due to AVAILABILITY_REPLICA error message in SQL Ser…
- After switching the tidb database, an error could not commit JDBC transaction appears from time to time
- Spring failed to commit the transaction
- yum install Transaction Check Error
- JPA transaction problems executing an update / delete query
- Solve “error: failed to commit transaction” in arch Linux
- Asset database transaction committed tweet appears when unity reports an error!
- Common mistakes in WCF distributed development (15): Communication with the underlying transaction manager has failed.
- The solution of transaction check error when installing Gnome with Yum command
- Spring configuration transaction, JUnit unit test error “failed to load ApplicationContext”
- Stata external commands: the most common and up-to-date commands
- When linux installs rpm, it prompts: can’t create transaction lock on /var/lib/rpm/.rpm.lock error
- Error lnk1120: 2 unresolved external commands: vtkrenderingopengl_ Autoinit (construct, destroy), which is referenced in
- The back end cannot receive the parameters passed by the front end