Skip to content

Support for optimistic locking [DATAJDBC-219] #445

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

Closed
spring-projects-issues opened this issue May 22, 2018 · 6 comments
Closed

Support for optimistic locking [DATAJDBC-219] #445

spring-projects-issues opened this issue May 22, 2018 · 6 comments
Assignees
Labels
type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link

Jens Schauder opened DATAJDBC-219 and commented

If there is a @Version  annotated attribute in an Aggregate Root the update on the Aggregate Root should check that the version has the current value and increment that value.

If the update fails due to that version check an exception should get thrown


Issue Links:

  • DATAJDBC-312 Support for optimistic locking on Aggregate Roots
    ("is duplicated by")

Referenced from: pull request #166

3 votes, 7 watchers

@spring-projects-issues
Copy link
Author

Tom Hombergs commented

I'd like to give this one a try. This is what I came up with:

  • on insert, if a @Version field is present, set version value to 1 (in DefaultDataAccessStrategy.insert())
  • on update, if a @Version field is present
    • add condition "WHERE version_field = :oldVersion" to update statement (add a new method getUpdateWithVersion() or similar to SqlGenerator)
    • if no row was updated, someone else must have updated the row in the meantime and we throw an OptimisticLockingFailureException (in DefaultDataAccessStrategy.update())

Does that make sense? Is DefaultDataAccessStrategy the right place to attack? 

BTW: if you currently add a @Version field and perform an update on an entity, Spring Data JDBC will try to do an insert instead (and fail due to a unique constraint if you have a unique ID column). The reason is that the entity is interpreted as a new entity because the version is still 0. This would be fixed by the above approach because the version field would be properly updated

@spring-projects-issues
Copy link
Author

Tom Hombergs commented

In the list above, I forgot:

  • on update
    • add "set version_field = version_field + 1" to update statement
    • probably we also want to increment the version in the entity object itself so the client will receive the new version

@spring-projects-issues
Copy link
Author

Jens Schauder commented

Yes, that sounds right. 

And we definitly need to update the version in the entity

@spring-projects-issues
Copy link
Author

Tom Hombergs commented

Thanks, I'll get to it, then :)

@spring-projects-issues
Copy link
Author

Tom Hombergs commented

Pull request: #124

@spring-projects-issues
Copy link
Author

Tyler K Van Gorder commented

I have an updated PR that includes the work that Tom Hombergs started that can be found here: #166

 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants