Concurrency control in REST API with Spring Framework

Transcript

1. @bartekslota Concurrency control in REST API with Spring Framework
2. Consultant/Trainer/Mentor @ Software Engineer Speaker Blogger Bartłomiej Słota @bartekslota bartslota.com bartlomiej.slota@gmail.com github.com/bslota linkedin.com/in/bslota
4. HANDLING CONCURRENT ACCESS Full-state comparison Locking Pessimistic Optimistic
5. IS THIS A TECHNICAL PROBLEM? Let’s talk about circumstances, where two patrons try to place the same book on hold and only one wins. Is there any situation in which we simply cannot tell our user that he/she had a bad luck trying to place the book on hold? Yes. When the patron is a premium one, you should send me an email and I will contact that person directly. We often try to find a copy for him cancelling the reservation of some other patron or buying a new copy.
6. 409 CONFLICT RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict. Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might use a 409 response to indicate that it can’t complete the request. In this case, the response representation would likely contain information useful for merging the differences based on the revision history.
7. CONDITIONAL REQUESTS RFC 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests Conditional requests are HTTP requests [RFC7231] that include one or more header fields indicating a precondition to be tested before applying the method semantics to the target resource.
8. ETag RFC 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests ETag = [W/]”{opaque-tag}” W/ - case sensitive weak validation optional indicator opaque-tag - mandatory string value surrounded by double quotes Examples: • ”” • ”123” • W/”my-weak-tag”
9. Preconditions RFC 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests Headers defining conditional requests: •If-Match •If-Not-Matched •If-Modified-Since •If-Unmodified-Since •If-Range
10. Preconditions evaluation RFC 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests A server MUST ignore all received preconditions if its response to the same request without those conditions would have been a status code other than a 2xx (Successful) or 412 (Precondition Failed). In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.
11. Preconditions
12. Missing preconditions RFC 6585 Additional HTTP Status Codes The 428 status code indicates that the origin server requires the request to be conditional. Its typical use is to avoid the “lost update” problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict. By requiring requests to be conditional, the server can assure that clients are working with the correct copies.
13. Missing preconditions
14. Thank you! @bartekslota bartslota.com bartlomiej.slota@gmail.com github.com/bslota linkedin.com/in/bslota