Slide 1

Slide 1 text

@bartekslota Concurrency control in REST API with Spring Framework

Slide 2

Slide 2 text

Consultant/Trainer/Mentor @ Software Engineer Speaker Blogger Bartłomiej Słota @bartekslota bartslota.com [email protected] github.com/bslota linkedin.com/in/bslota

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

HANDLING CONCURRENT ACCESS Full-state comparison Locking Pessimistic Optimistic

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

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.

Slide 7

Slide 7 text

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.

Slide 8

Slide 8 text

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”

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

Preconditions

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

Missing preconditions

Slide 14

Slide 14 text

Thank you! @bartekslota bartslota.com [email protected] github.com/bslota linkedin.com/in/bslota