Race condition EBean 14 #3412
Comments
|
It appears the second connection is for a ImplicitReadOnlyTransaction which has its own connection. First connection is used: Second connection is used: |
|
It seems this setup maybe intended for use with a ReadonlyDatasource. But setting that up shows that the two nested getConnections both claim from the readonly datasource, thus does not solve the problem. (The first working get/return claims from the normal pool.) |
|
Below are the two stacktraces of the two claims for a connection without returning in between. The second stacktrace has two different requests objects in DefaultServer line 1429. They are constructed just above in line 1414. It would make sense that the second request reuses the readonly connection obtained by the first request. Under EBean 12 this nesting indeed does not happen. And if an explicit JTA transaction is started, both request use that connection. |
|
I was able to patch the behaviour by introducing a ThreadLocal variable in OrmQueryRequest.initTransIfRequired and solely for createReadOnlyTransaction store the first transaction within a thread, and return that on subsequent calls. Does not seem like the correct way to fix it, but it appears to work. |
|
Alternatively one can add to e.g. LoadManyRequest.createQuery code to use the existing transaction: if (this.transaction() != null) {
query.usingTransaction(transaction);
}Or in DefaultBeanLoader void loadMany(LoadManyRequest loadRequest) {
SpiQuery<?> query = loadRequest.createQuery(server);
query.usingTransaction(loadRequest.transaction());
executeQuery(loadRequest, query);
loadRequest.postLoad();
}This feels like a better approach. Where the last one seems like it could be the fix, because it mirrors loadBean in the same class. |
tbee
added a commit
to nedap/ebean
that referenced
this issue
Jun 7, 2024
rbygrave
added a commit
that referenced
this issue
Jun 7, 2024
Fix such that LoadManyRequest uses the parent requests transaction rather than obtain a new read only transaction to perform the fetch query.
rbygrave
added a commit
that referenced
this issue
Jun 7, 2024
…ogic into LoadBeanRequest Move the query creation, using transaction and configure into LoadBeanRequest. This code then looks more like that of LoadManyRequest.
rbygrave
added a commit
that referenced
this issue
Jun 7, 2024
#3412 Use existing/parent transaction with fetch query on ToMany paths
|
Any idea when a bugfix release will come out? |
|
Should be on the way to central, so should be available in about 20 minutes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We've just reverted back to EBean 12 from Ebean 14.3.0. We observe the following behavior:
A request comes in and EBean claims a connection from the pool. A few milliseconds later a second connection is requested. Normally both are released afterwards. Peachy.
However, if the load is high, the whole pool is drained by requests claiming their first connection, the remaining requests are waiting on the pool's semaphore. Then the requests that got their first connection attempt to get a second, and then also wait on the pool's semaphore. All threads are now blocked, with the only escape being the timeout.
I've got a cleaned log for one thread below:
You see a first correct get/return connection. The second get is also successful, but before returning that connection a third get (30 ms later) is attempted. The pool is exhausted at that time.
What has changed in EBean 14 that it requires two connections?
I'l continue my investigation.
The text was updated successfully, but these errors were encountered: