-
Notifications
You must be signed in to change notification settings - Fork 368
Introduced pessimistic locks for derived queries. #1158
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
Introduced pessimistic locks for derived queries. #1158
Conversation
Methods which use the derive query functionality now can be annotated with `@Lock` to used a given `LockMode`. Right now there are two different modes `PESSIMISTIC_READ` and `PESSIMISTIC_WRITE`. Based on the dialect the right select is generated. For example for HSQLDB `Select ... FOR UPDATE`. Related tickets spring-projects#1041
Methods which use the derive query functionality now can be annotated with `@Lock` to used a given `LockMode`. Right now there are two different modes `PESSIMISTIC_READ` and `PESSIMISTIC_WRITE`. Based on the dialect the right select is generated. For example for HSQLDB `Select ... FOR UPDATE`. See #1041 Original pull request #1158
Refactored the unit tests to include a negative case and to separate the different scenarios tested. Removed the default LockMode from the Lock annotation. I have the feeling that most users will assume an exclusive Lock when none is specified, but also don't want to request stronger locks than required. Original pull request #1158 See #1041
Thanks for the PR that is polished and merged.
It does not solve #1041 since that one asked for the same thing, but for Spring Data R2DBC.
If you happen to be interested in tackling that as well, it would be highly appreciated.
Thanks for the PR that is polished and merged.
It does not solve #1041 since that one asked for the same thing, but for Spring Data R2DBC.
Oh ok I don't know why I thought that 😅 . I am quite confused why is this issue then in the spring-data-jpa and not Spring Data R2DBC?
If you happen to be interested in tackling that as well, it would be highly appreciated.
If I find time for it I will take a closer look at it, but my R2DBC knowledge is quite limited...
I am quite confused why is this issue then in the spring-data-jpa and not Spring Data R2DBC?
Well it's in spring-data-jdbc not spring-data-jpa 😂
Since both modules spring-data-jdbc and spring-data-r2dbc rely on spring-data-relational which is an artifact build from the spring-data-jdbc repository, it gets easy to get confused.
In the not to far future spring-data-jdbc and spring-data-r2dbc will get moved into one repository.
I'm not sure though if this will be helpful on the confusion front.
Well it's in
spring-data-jdbcnotspring-data-jpa😂
Yeah I wrote spring-data-jpa by mistake 😂
In the not to far future
spring-data-jdbcandspring-data-r2dbcwill get moved into one repository. I'm not sure though if this will be helpful on the confusion front.
I think this won't make it better 😅 because when I hear "r2dbc" I instantly think about "reactive" and when I hear "jdbc" the last thing that comes to my mind is "reactive" 😅 , but maybe with clear documentation this should not be a problem
when I hear "r2dbc" I instantly think about "reactive" and when I hear "jdbc" the last thing that comes to my mind is "reactive"
And that is absolutely correct. But both use SQL to access relational databases, so they already have a lot in common and in the future will share even more code.
Methods which use the derive query functionality now can be annotated with `@Lock` to used a given `LockMode`. Right now there are two different modes `PESSIMISTIC_READ` and `PESSIMISTIC_WRITE`. Based on the dialect the right select is generated. For example for HSQLDB `Select ... FOR UPDATE`. See #1041 Original pull request #1158
Refactored the unit tests to include a negative case and to separate the different scenarios tested. Removed the default LockMode from the Lock annotation. I have the feeling that most users will assume an exclusive Lock when none is specified, but also don't want to request stronger locks than required. Original pull request #1158 See #1041
It does not solve #1041 since that one asked for the same thing, but for Spring Data R2DBC.
@schauder
This should now be implemented with spring-projects/spring-data-r2dbc#720
This allows both Spring Data R2DBC and Spring Data JDBC to use the same annotation. See /issues/1041, spring-projects/spring-data-r2dbc/pull/720, /pull/1158
This allows both Spring Data R2DBC and Spring Data JDBC to use the same annotation. See /issues/1041, spring-projects/spring-data-r2dbc/pull/720, /pull/1158
Methods which use the derive query functionality now can be annotated with `@Lock` to used a given `LockMode`. Right now there are two different modes `PESSIMISTIC_READ` and `PESSIMISTIC_WRITE`. Based on the dialect the right select is generated. For example for H2 `Select ... FOR UPDATE`. Closes #1041 See #643, Original pull request /pull/1158
Uh oh!
There was an error while loading. Please reload this page.
Methods which use the derive query functionality now can be annotated with
@Lockto used a givenLockMode. Right now there are two different modesPESSIMISTIC_READandPESSIMISTIC_WRITE. Based on the dialect the right select is generated. For example for HSQLDBSelect ... FOR UPDATE.Related tickets #1041