-
Notifications
You must be signed in to change notification settings - Fork 356
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. |
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 I find time for it I will take a closer look at it, but my R2DBC knowledge is quite limited... |
Well it's in Since both modules In the not to far future |
Yeah I wrote
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 |
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
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
Methods which use the derive query functionality now can be annotated with
@Lock
to used a givenLockMode
. Right now there are two different modesPESSIMISTIC_READ
andPESSIMISTIC_WRITE
. Based on the dialect the right select is generated. For example for HSQLDBSelect ... FOR UPDATE
.Related tickets #1041