Assume two instances, say, A and B, of the same service X are available in a clo
ID: 3890950 • Letter: A
Question
Assume two instances, say, A and B, of the same service X are available in a cloud application. Both A and B can perform exactly the same INSERT INTO statement when either of them is requested to insert a new student into a database table.
When a client, C, requests X, it is re-routed to B because its initial request of X has been time out on A, although A is not 'dead' but only responds slowly. When X is just completed by B and A becomes available to serve C's original request, what would occur? Is X an idempotent service? Explain your answer.
To prove your answer of this question, follow the instructions below.
Create a simple small database with a Students table (containing any columns but at least one primary key) using a DBMS of your selection (e.g., Access, MySQL, Oracle, MS SQL Server, SQLite, etc.) and insert the same student record twice to simulate the above instances of A and B.
Explanation / Answer
Create MySQL DataBase :
CREATE DATABASE stdentdb ;
Sql query for creating student table :
CREATE TABLE Students(
ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int,
PRIMARY KEY (ID)
);
Idempotence :
Idempotence is a word that often hooks people. Idempotence is sometimes a ambiguity topic, at least from the academic definition.
From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that similar calls repeatedly while producing the similar result. In another way, making multiple similar requests has the similar effect as making a single request. Note that while idempotent operations produce the similar result on the server (no side effects), the response itself may not be the similar(e.g. a resource's state may change between requests).
The PUT and DELETE methods are defined to be idempotent. However, there is a caveat on DELETE. The problem with DELETE, which if successful would normally return a 200 (OK) or 204 (No Content), will often return a 404 (Not Found) on subsequent calls, unless the service is configured to "mark" resources for deletion without actually deleting them. However, when the service actually deletes the resource, the next similar request will not find the resource to delete it and return a 404. However, the state on the server is the similar after each DELETE call, but the response is different.
GET, HEAD, OPTIONS and TRACE methods are defined as safe, meaning they are only intended for retrieving data. This makes them idempotent as well since multiple, similar requests will behave the same.