MCPA MuleSoft Certified Platform Architect Level 1 – Designing Effective APIs Part 5

8. Optimistic Concurrency Control

In this lecture, let us discuss about how to control the concurrency in an optimistic way for these Http based Rest resources. Okay, so like any other project generally the concurrency plays a key role and there might be concurrent requests coming and hitting us a particular resource, correct? And we have to take care of this again in the API implementation side side to make sure that the resources are being updated or performed actions on in a proper way without causing any issues because of this concurrency.

Okay, so what happens generally is during these concurrency parts, especially when there are some concurrent reads and concurrent rights. Most of the times, what happens is the reads which are concurrently happening may cause a wrong or stale rights on the subsequent request. Because we read, say, some value X parallelly, someone is updating to a value to value Y.

But later, when a subsequent update comes, the resource who read the value X may try to update it back with X. Okay, so you know, I mean what are concurrent issues, race conditions, et cetera. So how to optimistically control such kind of things in here is so Http. Again, like we discussed about the item potent methods and the Caching safe Http methods even here during the Caching we discuss some Http tags headers, right, which are default ones, okay, so we’ll discuss about them.

So Http supports optimistic concurrency control of this kind of behaviors to control meaningful way natively. So with the combination of the facilities that we are about to discuss, we can achieve this behavior if implemented properly and designed well. So this feature is for immediately available for the Rest. Because they’re http based Because they are Http based, these Http had all are implicitly available. They are not like a custom one to be created. Okay, so what are those? You have seen them already before in the Caching lecture where we said there is e tag if match kind of tags, correct.

So this etag and if match tag together can actually be used to make sure that the concurrency can be done well. So how so etag is a Http response header tag. Actually it can be requested as well, but initiates the first time from the response okay header. So Etag it’s Http response header that needs to be sent by the APA implementation to the APA client by putting in a particular resource version ID in the response. So before after accepting the request and before sending the response, the APA implementation can inject Http response header called etag with a particular resource version ID. Okay, then the if match is Http request header that is to be sent by the APA client to the AP implementation by injecting the resource version ID that the APA client holds at that point of time with the client.

Okay, so this is to send the resource version ID on which an update is based http like it could be a put post patch, whatever the client has to put in version ID they have in the match in the request and send to the implementation. So what happens? There are two chances again. One is the client may get back error code called http four one two, which is semantically mean that precondition failed client error response code. Okay, so this is to inform the APA client that the resource version ID is sent, which was sent was tail and hence the requested change cannot be performed. Okay, so there could be another error which is say http four two eight which is semantically meaning precondition required client response error code.

What is the precondition required? It means it is to inform the APA client that the resource in the whatever we are about to call is protected against the concurrent modification and hence requires the if match Http request header which was missing from your request. Okay, so this can be used in such a way so that whenever http response goes back, a particular version ID goes back in the e tag, the client should store that against their side. And whenever they do subsequent updates like on the put to post on the patch in the future they have to inject the if match http request shutter with the version they have now.

On the implementation side, the logic is simple. Whatever the version that comes in the if match will be compared against the latest version which is on the AP implementation side. If it matches, then it means, okay, they are trying to perform an update on the latest resource so they will continue with it. If it is old one, that means they’re trying to send some data which is stale, are no longer valid. So they can reject with that four one two error, saying it’s a stale error and if they miss it all together that right, if match reader in the request, then that precondition required error will come again. How will the client know that they have to follow this? As usual, it’s a repeated thing. Might be boring you, I might be boring you, but please, this has to be digested in the APA world. Have to make sure this is reflected in the Ramble definition as a trite.

Okay, let you know how the RAML fragments can be created in the form of trite. Right? Making sure that okay in the response will get detailed in the request if match is compulsory for this particular resource because it is a candidate for the concurrent modifications. So you have to have this if match as a compulsory mandated trite request header so that clients are enforced to send this particular value. Okay? So for example, now let us see sample how it looks in front of you. So what you are seeing in front of you is like there are two clients API, client one and a client two and trying to call AP implementation. Okay? So the first time they did a retrieve for example, and in the retrieve they got a particular version with V 42 in the etag back. Okay? The client one got V 42 and after some time a client two also called the AP implementation, client two also got etag with a version called V 42 because v 42 is the latest version that the AP implementation has. So all good to the get method is they got the latest version, both of them hold the latest version happy. Now what happens is client one, even though they got the Etag version, let’s say they tried the put or post or past method without the if match header, okay, for this particular resource where the trade is implemented and enforced, then what happens? Immediately the implementation will throw error back saying hey buddy, you missed the if match header, so I’m giving you a precondition required error.

Then they know that oh okay, I missed the if match header, how to put that before to ensure. So meanwhile when this API client one is fixing the stuff to inject that header and all this client to what the client who did client to do? Posted proper request with put post method whatever method as the tech. Is exposed to them. Whatever method one of these methods they used and they sent the if match with the proper version received before V 42. And now the resource is updated successfully. And after the update, the implementation now gave back a new e tag version saying hey, thank you for updating my resource. Now this is the latest version, keep it with your V 43. So client two got the V 43, but however, because client one has not got the latest version details yet, now retried with the old version, they got the V 42 which if match and all properly but no use because it’s an old outdated version, right?

It’s a stale one. So again they got error back saying this time it’s a precondition failed because you are using a stale resource. But even in the failure message also the AP implementation should put the version back the latest version back in the response which is etag v 43 because the reason is otherwise it’s an unnecessary extra call waste for the client to very specially again one more time to get the latest version right because they already got the error.

So okay, they understand it’s a stale one. So how do they get the new one? They have to unnecessarily make one more get call. So to save that call, if the AP reputation can inject even in success and error messages the latest version every time, then it is handy for the clients to inject that one and proceed with the next logic. Okay? So this is the most optimistic way to control the concurrency related issues in the SDP based Rest API. So hope you understood the concept. This is also one of the architectural pattern in the APA world that has to be implemented. All right? Happy learning.

• Category: Uncategorized