-
Notifications
You must be signed in to change notification settings - Fork 0
No longer block the tomcat thread when waiting for geodata (servlet 3.0+ AsyncContext) #162
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
Conversation
….0+ AsyncContext) The @transactional was already unneeded, it didn't propagate to the executor thread Effectly it opened a transaction and instantly closed it. Spring forces us to adapt the tests with boilerplate code (asyncStarted() and asyncDispatch()) as per https://docs.spring.io/spring-framework/reference/testing/mockmvc/hamcrest/async-requests.html to mimic the servlet 3.0 redispatch
| }; | ||
| } | ||
|
|
||
| @Transactional(readOnly = true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we move this Transactional somewhere else ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest in a separate PR ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(also in this case it looks like all the computation is just a single repository call to the standard find method so it should be equivalent I think.. not 100% sure from the top of my head though. Also not sure what is the official code to do transactions in a separate thread.. probably it's just the same but I would need to double check..)
| } else { | ||
| return getSubstationsByCountries(network, countrySet); | ||
| } catch (Exception e) { | ||
| throw new GeoDataException(FAILED_SUBSTATIONS_LOADING, e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it behave the same to throw inside or outside the async ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes it's the same. And there are unit tests that verify that from an http client point of view, the thrown exception inside the completablefuture is correctly used by the servlet container asynchronously to return the associated error http reponse to the client
Signed-off-by: HARPER Jon <jon.harper87@gmail.com>
|



The @transactional was already unneeded, it didn't propagate to the executor thread Effectly it opened a transaction and instantly closed it.
Spring forces us to adapt the tests with boilerplate code (asyncStarted() and asyncDispatch()) as per https://docs.spring.io/spring-framework/reference/testing/mockmvc/hamcrest/async-requests.html to mimic the servlet 3.0 redispatch