prevent read-only from polluting subsequent usage of thread#246
Open
njr-11 wants to merge 1 commit intojakartaee:masterfrom
Open
prevent read-only from polluting subsequent usage of thread#246njr-11 wants to merge 1 commit intojakartaee:masterfrom
njr-11 wants to merge 1 commit intojakartaee:masterfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #245
This adjusts the design of read-only transactions prevent a highly likely scenario where read-only is left around after a transaction and pollutes subsequent transactions that unknowingly roll back, losing data.
One way for this to happen is if you have existing code that uses transactions and, prior to that point, you insert an invocation into other code (could be third-party, whatever) that uses UserTransaction.setReadOnly to run a read only transaction. Unless that code was nice enough to set read-only back to false after it ends, the subsequent transactions unknowingly start running in read-only mode, too.
The solution, discussed in #245 and in another issue under Jakarta Connectors, is to scope the read-only behavior to the single transaction for which it is explicitly requested. It then becomes impossible to accidentally impact other transactions.