Prevent Oracle from committing uncommitted transactions on connection close #45301
Conversation
… close When a connection is closed, Oracle will commit the unfinished business, which is a very surprising behavior in most cases and could lead to data loss. I added a -Dquarkus-oracle-no-automatic-rollback-on-connection-close to disable this behavior if absolutely needed. If we have feedback that this is not something we should do always, we can add a proper configuration property (with a default value to determine). Fixes quarkusio#36265 Wouldn't have been possible without the nice work of @segersb and @Felk. Co-authored-by: Felix König <[email protected]>
quarkus-bot
bot
added
area/docstyle
This comment has been minimized.
This comment has been minimized.
|
🎊 PR Preview 35ccb2e has been successfully built and deployed to https://quarkus-pr-main-45301-preview.surge.sh/version/main/guides/
|
This comment has been minimized.
This comment has been minimized.
|
Let's make sure @yrodiere is on board with this before merging. It obviously will require a note in the migration guide. |
| return; | ||
| } | ||
|
|
||
| oracleConnection.rollback(); |
There was a problem hiding this comment.
I understand that rolling back a transaction that was already committed will just do nothing, but I wonder if it could mess with metrics... Maybe an if (transaction in progress) -- if possible at all -- would be safer?
Co-authored-by: Yoann Rodière <[email protected]>
Co-authored-by: Yoann Rodière <[email protected]>
Co-authored-by: Yoann Rodière <[email protected]>
Status for workflow
|
Status for workflow
|
When a connection is closed, Oracle will commit the unfinished business, which is a very surprising behavior in most cases and could lead to data loss.
I added a -Dquarkus-oracle-no-automatic-rollback-on-connection-close to disable this behavior if absolutely needed.
If we have feedback that this is not something we should do always, we can add a proper configuration property (with a default value to determine).
Fixes #36265
Wouldn't have been possible without the nice work of @segersb and @Felk.