-
-
Notifications
You must be signed in to change notification settings - Fork 263
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
ManyToMany fakes delete statements?! #3229
Comments
Do you have a failing test case then? Reading this it almost seems like you have.
This is at position 20 which is the default batch size (as per DatabaseConfig). Now what ebean is logging with the The above looks suspiciously like the
This suggests the app is using an external transaction manager and probably the Spring transaction manager? Is that correct? |
It would be useful to have the full stack trace and importantly the part of the stack trace that shows what ebean code was being executed. We are interested in what ebean code (stack trace) was flushing the inserts before all the queued deletes had the executeBatch() called on. Only including the mysql driver code is less useful. |
I'll get you the stacktrace. We're using a modified JTATransactionManager, based on the one in EBean sources, in order to disable all batching (because of another issue: #3208). Batching seems to be seriously broken in the 12 branch and it is not possible to disable it with configuration. So we're not using the Spring transaction manager. We do not have a test case, but a failing test scenario. I know you do not like to backport to 12, so for now we patch everything, and after the Java upgrade revisit the issues (we're at 5 issues now) based on the 13 branch. |
|
Apparently the |
FYI: Note the change to
There is a branch for 12 called
Well I think that is what we are looking for. If we can see where that is in the code and why then we might be able to reverse engineer a failing test. |
We do not plan to stick around on 12 for long. It's just an intermediate stop so we can upgrade from Java 8 to 17. EBean 13 comes right after that. |
We're at EBean 14 now. But batching is not working (see #3363) so we cannot revisit this one. |
So you are not trying to create a failing test case for this one? Or it's more that you are waiting for more progress on #3363 before you start creating a failing test case? |
Because it turns out that our code base cannot run with batching enabled, we cannot revisit this issue. I'll close it. |
Expected behavior
We have the following setup:
Actual behavior
Under EBean 12.16.1, when the AuthorizationAssignment is saved, we see the following lines in EBean's logging:
At which point MySQL throws an exception:
In MySQL's log we see the following lines:
EBean's log claims to have executed delete statements after the
bind(1, 4)
line, but these are not visible in MySQL's log. And as a result the exception is correct. This reeks like a batching issue.In PersistRequestBean, irrespective of if batching is enabled, the completeUpdate always batches the many to many relations. Like the line in DefaultPersister.update, there should be a
saveExecuteOrQueueMany()
Building a custom EBean version where saveBatch has hardcoded false for queue makes the problem go away.
The text was updated successfully, but these errors were encountered: