-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong transaction state for broken database connection #40489
Comments
/cc @mmusgrov (narayana) |
The after failure observer method should only be called if the transaction rolls back, but if it rolled back then the database will be instructed to rollback the entity state that got written to the db. So if the entity did get committed then I see a few possibilities:
Since Narayana is only responsible for registering and calling the Arc Synchronization, and since it invoked the notification on the Arc Synchronization (the bug report said it received an AFTER_FAILURE notification), I plan to remove the "area/narayana" label. |
I guess we need some logs to make further progress (hibernate and narayana and the connection management code should be sufficient). |
To be honest, I don't know which logs I could provide here, as there are a lot of exceptions in the log due to the frequent connection terminations, for example. I'm not sure which of these are to be expected and which might indicate the problem. I thought my reproducer could help you with this. Perhaps the following warning is relevant, but I'm not that familiar with the topic:
What I find strange about the stacktrace is that you can see |
Describe the bug
If the database connection is interrupted while we are persisting an entity in a transaction, it may be that the entity has been persisted in the database, but we are not aware of this via our transaction observers, or that the wrong observer is being called.
Example code
We have a simple method which creates/persists the entity and fires an event:
Within a bean, we have multiple observers:
Now we are faced with the problem in our (real) applications that if we have a problem with the database connection during the persistence of the entity (e.g. because the database was restarted, a network error occurred, etc.), the
AFTER_FAILURE
observer is called, but the entity was successfully persisted.This is an inconsistent state and we cannot know whether the entity has really been persisted or not - without performing another check on the database. This might not be a big problem for simple applications, but for generic implementations, or if you don't know what may or may not have been (partially) persisted in the transaction, then this is a very big problem for us.
Hint: We have the same problem when using an implementation of
jakarta.transaction.Synchronization
. Also here the status in theafterCompletion
method is the wrong one (Status.STATUS_ROLLEDBACK
instead ofStatus.STATUS_COMMITTED
).Please let me know if I need to create an issue at another location / project.
Expected behavior
The status of the transaction must reflect whether entities have been persisted or not. It must not be the case that entities have been persisted but we are not aware of this. The same applies in the opposite case, of course.
Or to put it another way: We must be sure that the status of the observers is consistent with regard to the database operations.
Actual behavior
Entities may have been successfully persisted to the database, but we get the information that the transaction failed.
How to Reproduce?
Reproducer: https://github.com/timonzi/transaction-phase-reproducer
Execute the
PersistenceTest
.What it does:
Hint: We create so many entities and kill the connections so often because it is not clear to me at which point the problem exists. It can happen of course also when the database connection is lost only once (as said, because of Database restart, network problem, etc.)
What can we see:
Example log output:
Output of
uname -a
orver
Linux nb-timonz 6.5.0-28-generic #29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr 4 14:39:20 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -version
OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
Quarkus version or git rev
3.9.3 (but I think the problem occurs in all Quarkus versions)
Build tool (ie. output of
mvnw --version
orgradlew --version
)Apache Maven 3.9.3
Additional information
No response
The text was updated successfully, but these errors were encountered: