Skip to content
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

Improve concurrent save/insert optimistic locking [DATACOUCH-224] #534

Closed
spring-projects-issues opened this issue May 3, 2016 · 5 comments
Closed
Labels
type: bug

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented May 3, 2016

Anastasiia Smirnova opened DATACOUCH-224 and commented

Follow-up on DATACOUCH-212. While the former has been resolved in its basic form, Aloren has raised concerns that the case of multiple concurrent saves (and even inserts) has not, as no OptimisticLockingException is raised in such a case


Affects: 2.1.1 (Hopper SR1)

Issue Links:

  • DATACOUCH-212 Optimistic Locking is not working when using Repository save method
    ("depends on")

Referenced from: commits c6b5ecc, 811c024

Backported to: 2.1.2 (Hopper SR2)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 27, 2016

Eduard Dudar commented

This change introduced some unexpected consequences as for the patch version. Documents that were routed to upsert branch of SAVE operation before are routed to insert (there's versionProperty but there's no version value) now and fail because of key duplication

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 27, 2016

Simon Baslé commented

The assumption is that if you're using an @Version annotated property, you want CAS. So either the document doesn't previously exists, in which case you cannot have a version, and that translates to an insert, or you want to update an existing entity, in which case you want CAS and thus should provide a version.

If you don't want insert+CAS, but rather upsert, then you probably don't need a version property?

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 27, 2016

Eduard Dudar commented

That's true, in my use case all CB accessors produce consistent result on a particular key at a given time so even when one of them updates document the rest are fine to do nothing/overwrite it. I'm not questioning the change itself, it looks good and proper. My point is that replacement of upsert with insert is restrictive and so potentially breaking as it was in my case

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 28, 2016

Simon Baslé commented

So do you think it should be better documented somewhere as a breaking change? (not sure where though, I'm open to suggestions ;) )
Did you have anything else in mind to improve the situation?

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 28, 2016

Eduard Dudar commented

I think ideally changes like this is better to defer until next minor release at least such is upcoming 2.2. As far as documentation at http://docs.spring.io/spring-data/couchbase/docs/2.1.2.RELEASE/reference/html/ has no section about changes it might be beneficially to add notes to https://github.com/spring-projects/spring-data-couchbase/releases? Or add such section to official docs if github is for code only

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

No branches or pull requests

1 participant