DEV Community: Abinaya Dhanraj

Understanding ALTER TABLE with Constraints in SQL

Abinaya Dhanraj — Sun, 29 Mar 2026 02:55:29 +0000

_In this task, I worked on modifying existing tables using ALTER TABLE. This helped me understand how to update table structure after it has already been created. I learned how to add constraints, change column properties, and manage relationships between tables.
_

Modifying customers table

Query:

ALTER TABLE customers
ALTER COLUMN email SET NOT NULL;

Explanation:

In this query, I modified the email column so that it cannot store NULL values. This ensures that every customer must have an email in future entries.

Adding UNIQUE constraint in users table

Query:

ALTER TABLE users
ADD CONSTRAINT unique_username UNIQUE (username);

Explanation:

Here, I added a UNIQUE constraint to the username column. This ensures that no two users can have the same username, which helps avoid duplicate records.

Adding CHECK constraint in products table

Query:

ALTER TABLE products
ADD CONSTRAINT check_price_positive CHECK (price > 0);

Explanation:

In this query, I added a CHECK condition to make sure that the price is always greater than 0. This prevents invalid values like zero or negative prices.

Setting DEFAULT value in orders table

Query:

ALTER TABLE orders
ALTER COLUMN status SET DEFAULT 'pending';

Explanation:

Here, I set a default value for the status column. If no value is provided while inserting data, it will automatically be set to 'pending'.

Adding salary column in employees table

Query:

ALTER TABLE employees
ADD COLUMN salary DECIMAL(10,2) NOT NULL CHECK (salary > 10000);

Explanation:

In this query, I added a new column called salary. It cannot be NULL and must always be greater than 10000. This ensures that all employees have a valid salary value.

Modifying foreign key with cascade

Query:

ALTER TABLE employees_dept
DROP CONSTRAINT employees_dept_department_id_fkey;

ALTER TABLE employees_dept
ADD CONSTRAINT employees_dept_department_id_fkey
FOREIGN KEY (department_id)
REFERENCES departments(id)
ON DELETE CASCADE;

Explanation:

Here, I modified the foreign key constraint. When a department is deleted, all related employees will also be deleted automatically. This helps maintain consistency in the database.

Removing CHECK constraint in accounts table

Query:

ALTER TABLE accounts
DROP CONSTRAINT accounts_balance_check;

Explanation:

In this query, I removed the CHECK constraint that was enforcing balance to be greater than or equal to 0. After removing it, the table will allow any value for balance.

Adding composite UNIQUE constraint in payments table

Query:

ALTER TABLE payments
ADD CONSTRAINT unique_user_transaction UNIQUE (user_id, transaction_id);

Explanation:

Here, I added a composite UNIQUE constraint on user_id and transaction_id. This ensures that the same transaction cannot be repeated for the same user.

Conclude with :

Through this task, I understood how ALTER TABLE helps in modifying existing tables. It allows adding, removing, and updating constraints based on new requirements.This made me realize that database design is not fixed and can be updated when needed, but changes should be done carefully to maintain data consistency.

Understanding SQL Table Creation with Constraints Introduction

Abinaya Dhanraj — Sun, 29 Mar 2026 02:47:48 +0000

_In this task, I created different tables in SQL by applying various constraints. While writing these queries, I focused on understanding why each constraint is used and how it helps in maintaining proper data in the database.

Students Table

Query:

CREATE TABLE students (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
age INT
);

Explanation:

In this table, I created three columns: id, name, and age. The id is defined as a primary key, which means each record will have a unique identifier. I used SERIAL so that the id is automatically generated. This avoids duplication and makes it easier to identify each student.

Employees Table

Query:

CREATE TABLE employees (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
email VARCHAR(100) NOT NULL,
phone_number VARCHAR(15)
);

Explanation:

In this table, name and email are marked as NOT NULL, which means these fields cannot be left empty. The phone_number is optional, so it can have null values. This ensures that important details are always stored.

Users Table

Query:

CREATE TABLE users (
id SERIAL PRIMARY KEY,
username VARCHAR(50) UNIQUE,
email VARCHAR(100) UNIQUE
);

Explanation:

Here, I used UNIQUE for both username and email. This ensures that no two users can have the same username or email. It helps prevent duplicate entries and maintains consistency.

Products Table

Query:

CREATE TABLE products (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
price DECIMAL(10,2) CHECK (price > 0),
stock INT CHECK (stock >= 0)
);

Explanation:

In this table, I used CHECK constraints to control the values. The price must be greater than zero, and stock must be zero or more. This prevents invalid data like negative stock or incorrect pricing.

Orders Table

Query:

CREATE TABLE orders (
id SERIAL PRIMARY KEY,
status VARCHAR(20) DEFAULT 'pending',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Explanation:

In this table, I used default values. If no status is given, it will automatically be set to 'pending'. The created_at column stores the current timestamp, which helps in tracking when the order was created.

Accounts Table

Query:

CREATE TABLE accounts (
id SERIAL PRIMARY KEY,
account_number VARCHAR(20) UNIQUE NOT NULL,
balance DECIMAL(10,2) CHECK (balance >= 0)
);

Explanation:

Here, account_number is both UNIQUE and NOT NULL, so every account must have a unique value and it cannot be empty. The balance is restricted using a CHECK condition to ensure it is not negative.

Enrollments Table

Query:

CREATE TABLE enrollments (
student_id INT,
course_id INT,
UNIQUE (student_id, course_id)
);

Explanation:

In this table, I used a combination of student_id and course_id as UNIQUE. This means a student cannot enroll in the same course more than once, but can enroll in different courses.

Departments and Employees (Foreign Key)

Query:

CREATE TABLE departments (
id SERIAL PRIMARY KEY,
name VARCHAR(100)
);

CREATE TABLE employees_dept (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
department_id INT,
FOREIGN KEY (department_id) REFERENCES departments(id)
);

Explanation:

Here, I created two tables. The employees table has a foreign key called department_id, which refers to the id in the departments table. This ensures that every employee is linked to a valid department.

Foreign Key with Cascade

Query:

CREATE TABLE departments_cascade (
id SERIAL PRIMARY KEY,
name VARCHAR(100)
);

CREATE TABLE employees_cascade (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
department_id INT,
FOREIGN KEY (department_id)
REFERENCES departments_cascade(id)
ON DELETE CASCADE
ON UPDATE CASCADE
);

Explanation:

In this case, I added cascade options. When a department is deleted, all related employees are also deleted automatically. When a department id is updated, the change is reflected in the employees table. This helps maintain consistency without manual updates.

I conclude with :

From this task, I understood that constraints play an important role in maintaining correct and meaningful data. Each constraint serves a specific purpose, such as avoiding duplicates, preventing invalid values, and maintaining relationships between tables.

CREATING AN EC2 Instance and Running a Web Server

Abinaya Dhanraj — Wed, 25 Mar 2026 14:08:30 +0000

Title: Creating an EC2 Instance and Running a Web Server

In this task, I created a virtual server using Amazon Web Services and hosted a simple web server so I can access it from outside.

I used Amazon EC2 for this.

What is EC2

EC2 stands for Elastic Compute Cloud. It allows us to create virtual machines in the cloud and run applications on them.

Step 1: Launch EC2 instance

First, I logged into AWS console.

Then I went to EC2 service and clicked Launch Instance.

I entered the following details

Instance name as my-server
Selected Amazon Linux image
Instance type as t2.micro
Created a new key pair for login

Step 2: Configure network

I allowed HTTP traffic so that I can access the web server from browser.

In security group settings, I added

Type HTTP
Port 80
Source Anywhere

This step is important, otherwise the site will not open.

Step 3: Launch instance

After configuring everything, I launched the instance.

Then I waited until the instance state became running.

Step 4: Connect to instance

I connected to the instance using SSH.

Using terminal, I used the key pair file to login.

Step 5: Install web server

After connecting, I installed a web server.

Command
sudo yum install httpd -y

Then I started the service

sudo systemctl start httpd

Also enabled it

sudo systemctl enable httpd

Step 6: Add simple webpage

I created a simple HTML file.

Command
echo Hello this is my first server > /var/www/html/index.html

Step 7: Access from browser

Now I copied the public IP of the instance.

In browser, I entered the IP.

The webpage opened and showed my message.

What I understood

EC2 allows us to create servers easily.

Security group controls access like a firewall.

Web server like httpd is used to serve webpages.

Conclusion

By using EC2, I was able to create a server, run a web application, and access it from outside using a public IP. This is the basic idea behind hosting websites in the cloud.

Understanding IP Address and Subnet

Abinaya Dhanraj — Wed, 25 Mar 2026 14:05:02 +0000

Title: Understanding IP Address and Subnet in Simple Terms

In this blog, I am explaining what an IP address is and what subnet means, in a simple way based on what I understood.

What is an IP address

An IP address is a unique number given to every device connected to a network. It is used to identify and communicate between devices.

Just like how a house has an address, every system on the internet has an IP address.

Example of an IP address
192.168.1.1

This is called IPv4 format.

Types of IP address

There are mainly two types

Public IP address
This is used on the internet and is unique globally

Private IP address
This is used inside local networks like home or office

Example of private IP
192.168.x.x
10.x.x.x

Structure of IP address

An IPv4 address has 4 parts separated by dots.

Example
192.168.1.10

Each part can have values from 0 to 255.

What is subnet

Subnet means dividing a large network into smaller networks.

Instead of managing one big network, we split it into smaller parts for better control and performance.

Why subnet is used

To reduce network traffic
To improve security
To organize networks properly

Subnet mask

Subnet mask is used to identify which part of the IP address is network and which part is host.

Example
IP address: 192.168.1.10
Subnet mask: 255.255.255.0

Here
192.168.1 is network part
10 is host part

CIDR notation

Subnet can also be written using CIDR format.

Example
192.168.1.0/24

Here /24 means first 24 bits are for network.

Example of subnetting

If I have a network 192.168.1.0/24, it has 256 IP addresses.

Range
192.168.1.0 to 192.168.1.255

Now I can split this into smaller subnets like

192.168.1.0/25
192.168.1.128/25

Each subnet will have fewer IPs.

What I understood

IP address is used to identify devices in a network.

Subnet helps in dividing networks into smaller manageable parts.

Both are important for networking and cloud services.

Conclusion

IP address and subnet are basic concepts in networking. Understanding them helps in working with systems, servers, and cloud platforms more effectively

Setting up a DNS Hosted Zone in Amazon Route 53

Abinaya Dhanraj — Wed, 25 Mar 2026 14:00:50 +0000

Title: Setting up a DNS Hosted Zone in Amazon Route 53

In this task, I am setting up a hosted zone in Amazon Web Services using Amazon Route 53. This helps in managing DNS records for a domain.

What is a hosted zone

A hosted zone is a container for DNS records. It stores information about how domain names are mapped to IP addresses.

There are two types
Public hosted zone for internet access
Private hosted zone for internal use inside a VPC

Here I am creating a public hosted zone.

Step 1: Login to AWS

First, I logged into the AWS Management Console.

Then I searched for Route 53 in the services section.

Step 2: Open Hosted Zones

Inside Route 53, I selected Hosted Zones.

Then I clicked on Create Hosted Zone.

Step 3: Enter domain details

I entered my domain name like example.com.

Then I selected Public Hosted Zone.

After that, I clicked Create Hosted Zone.

Step 4: Hosted zone created

Now AWS created the hosted zone.

Inside it, I can see default records like

NS record
SOA record

These are automatically created by AWS.

NS record contains name servers provided by AWS.
SOA record contains domain authority details.

Step 5: Add DNS record

Now I added a new record.

I clicked Create Record.

Then I entered

Record name like www
Record type as A
Value as IP address of my server

Then I saved the record.

Step 6: Update name servers

To make this work, I copied the NS records from Route 53.

Then I went to my domain registrar and replaced the existing name servers with these AWS name servers.

This step connects my domain to Route 53.

Step 7: Testing

After some time, I tested the domain in browser.

Now the domain is resolving to the IP address I configured.

What I understood

Route 53 helps in mapping domain names to IP addresses.

Hosted zone is where all DNS records are stored.

NS records are important to connect domain with AWS.

Conclusion

Setting up a hosted zone in Route 53 is simple and important for managing DNS. It allows us to control how users reach our application using domain names instead of IP addresses.

How a Request Travels from Client to Server

Abinaya Dhanraj — Wed, 25 Mar 2026 13:57:57 +0000

Title: How a Request Travels from Client to Server

Whenever I open a website or click something in an app, a request is sent from my device to a server. This happens very fast, but there are multiple steps involved. In this blog, I am explaining how a request starts from the client and finally reaches the server.

What is a client and server

Client means the user side, like my mobile, laptop, or browser.
Server is a system that stores data and responds to requests.

Step 1: User action

The process starts when I do some action like typing a URL in the browser or clicking a button.

Example: I type amazon.com in the browser.

Step 2: DNS resolution

The browser cannot understand amazon.com directly. It needs an IP address. So it asks the DNS system to convert the domain name into an IP address.

After this step, the browser gets something like 54.x.x.x.

Step 3: Creating the request

Now the browser prepares an HTTP request.

This request contains method like GET or POST ,URL, headers
sometimes body data

Example: If I just open a website, it sends a GET request.

Step 4: TCP connection

Before sending the request, a connection must be established with the server.

This is done using TCP handshake.

Client sends SYN
Server replies with SYN-ACK
Client sends ACK

Now the connection is established.

Step 5: Sending the request

After connection is ready, the HTTP request is sent through the network.The request travels through routers and different networks on the internet.

Step 6: Reaching the server

The request finally reaches the server using the IP address.

The server receives the request and processes it.

It may fetch data from database run some logic prepare a response

Step 7: Server sends response

After processing, the server sends back an HTTP response.

This response contains status code like 200, 404 headers response body like HTML or JSON

Step 8: Client receives response

The browser receives the response.

If it is a webpage, it renders the HTML and shows it on the screen.

If it is API data, it processes it accordingly.

Step 9: Connection close or reuse

After response, the connection may be closed or reused for further requests.

What I understood

A simple click or typing a URL involves many steps like DNS lookup, connection setup, request sending, and response receiving.Even though it looks simple, many systems work together to make it happen.

Conclusion

The journey from client to server is an important concept in networking. Understanding this helps in learning web development, APIs, and system design in a better way.

DNS

Abinaya Dhanraj — Wed, 25 Mar 2026 13:52:21 +0000

Title: How DNS Resolver Works in Simple Steps

Whenever we open a website like google.com, we don’t actually know its IP address. But computers need IP addresses to communicate. So there is a process that happens behind the scenes to convert the domain name into an IP address. This process is called DNS resolution.

First, what is DNS

DNS stands for Domain Name System. It works like a phonebook of the internet. Instead of remembering numbers like 142.250.190.78, we just use names like google.com.

Now I will explain step by step what happens when I type a website in the browser

Step 1: Request from browser

When I type google.com in the browser, the browser first checks if it already knows the IP address.

It looks in browser cache. If found, it uses that directly.

If not found, it goes to the next step.

Step 2: OS cache check

The request goes to the operating system. It also checks its own cache.

If the IP is already stored, it returns it.

If not, then it goes to DNS resolver.

Step 3: DNS Resolver

DNS resolver is usually provided by the internet service provider.

Its job is to find the IP address for the domain.

If it already has the answer cached, it returns immediately.

If not, it starts asking other DNS servers.

Step 4: Root server

The resolver first contacts the root DNS server.

Root server does not know the exact IP, but it knows where to find the next level.

It tells the resolver to go to the TLD server.

Step 5: TLD server

TLD means Top Level Domain like .com, .org.

The resolver asks the .com server for google.com.

The TLD server responds with the address of the authoritative name server.

Step 6: Authoritative server

Now the resolver contacts the authoritative DNS server.

This server has the actual IP address of google.com.

It returns the IP address.

Step 7: Response back

The resolver sends this IP address back to the browser.

The browser now uses this IP to connect to the actual web server.

Step 8: Website loads

Finally, the browser sends HTTP request to that IP and the website loads.

Caching

At every step, caching is used.

Browser cache
OS cache
DNS resolver cache

This makes future requests faster.

What I understood

DNS resolver acts like a middle person. It does not always know the answer, but it knows how to find it step by step.

This process happens very fast, usually in milliseconds, so we don’t notice it.

Conclusion

DNS resolution is an important part of how the internet works. Without it, we would have to remember IP addresses for every website. It makes the internet easy to use by converting names into IP addresses automatically

ATOMICITY

Abinaya Dhanraj — Wed, 25 Mar 2026 13:48:16 +0000

In this task I am checking atomicity. That means a transaction should either fully complete or not happen at all.

First I check the initial data.

Query
select * from accounts;

Here I see Alice has 1000 and Bob has 500.

Now I perform a correct transfer.

Query
begin;

update accounts
set balance = balance - 300
where name = 'Alice';

update accounts
set balance = balance + 300
where name = 'Bob';

commit;

Here I deducted 300 from Alice and added 300 to Bob in the same transaction.

Now I check the data.

Query
select * from accounts;

Now Alice has 700 and Bob has 800. So both operations happened successfully.

Now I test what happens if something goes wrong after deducting money.

Query
begin;

update accounts
set balance = balance - 200
where name = 'Alice';

Now I introduce an error. I write a wrong column name.

update accounts
set bal = balance + 200
where name = 'Bob';

commit;

Here the second query fails because column bal does not exist.

Now I check the data again.

Query
select * from accounts;

I can see that Alice balance is still 700 and not reduced to 500.

This means even though the first update worked, it was not saved because the transaction failed.

The database automatically rolled back everything.

Now I try another case where I manually rollback.

Query
begin;

update accounts
set balance = balance - 100
where name = 'Alice';

rollback;

Now I check again.

Query
select * from accounts;

Alice balance is still 700. So rollback cancelled the change.

From this I understand atomicity clearly.

If all queries succeed and commit is given, changes are saved.
If any query fails, the entire transaction is cancelled.
No partial update will happen.

So in a wallet system, this is very important.

If money is deducted but not added to the receiver, it will cause loss.
Atomicity makes sure both actions happen together or not at all.

Finally what I understood is

Transaction works like one unit
Either everything inside it is saved
Or nothing is saved

This ensures safe money transfer without inconsistency.

DURABILITY

Abinaya Dhanraj — Wed, 25 Mar 2026 13:42:23 +0000

For this task, I am trying to understand durability. That means once a transaction is committed, the data should not be lost even if the system crashes.

First I check the current data in the table.

Query
select * from accounts;

Here I can see Alice has 1000 and Bob has 500.

Now I perform a money transfer from Alice to Bob.

Query
begin;

update accounts
set balance = balance - 200
where name = 'Alice';

update accounts
set balance = balance + 200
where name = 'Bob';

commit;

Here I started a transaction, deducted 200 from Alice and added 200 to Bob, and then committed it.

After commit, the changes are saved permanently.

Now I check the data again.

Query
select * from accounts;

Now I can see Alice has 800 and Bob has 700. This confirms that the transaction is successful.

Next step is to simulate a system crash or restart. In real scenario, this means database stops and starts again.

After reconnecting, I again run the same select query.

Query
select * from accounts;

I can still see Alice has 800 and Bob has 700.

So even after restart, the data is not lost.

From this I understand that once commit is done, the database permanently stores the data.

This is called durability.

Now I think about two situations.

If failure happens before commit
In this case, transaction is not completed. So PostgreSQL will rollback the changes automatically. Data will remain same as before.

If failure happens after commit
In this case, even if system crashes, the committed data will not be lost. When database restarts, it will restore the committed changes.

This is possible because PostgreSQL stores changes in logs internally before confirming commit. So even if crash happens, it can recover the data.

So finally what I understood is

Once commit is executed, the data is safe and will not be lost.
If commit is not done, changes will not be saved.

This ensures durability in the system and avoids data loss in applications like payment systems.

IDEMPOTENCY

Abinaya Dhanraj — Wed, 25 Mar 2026 13:38:06 +0000

For this task, I am trying to understand what happens when the same transaction runs more than one time. In real systems, this can happen if the network is slow or the request is sent again.

First I check the current balance in the accounts table.

Query
select star from accounts;

Here I am just viewing the data. For example, Alice has 1000 and Bob has 500.

Now I try to do a money transfer from Alice to Bob.

Query
begin;

update accounts
set balance = balance - 300
where name = 'Alice';

update accounts
set balance = balance + 300
where name = 'Bob';

commit;

Here what I am doing is deducting 300 from Alice and adding it to Bob. After commit, the transaction is saved.

Now Alice will have 700 and Bob will have 800.

Now I repeat the same transaction again.

Query
begin;

update accounts
set balance = balance - 300
where name = 'Alice';

update accounts
set balance = balance + 300
where name = 'Bob';

commit;

Here I am running the same transfer again. The database does not stop me. So again 300 is deducted from Alice and added to Bob.

Now Alice becomes 400 and Bob becomes 1100.

From this, I understand that the system is allowing the same transaction to happen multiple times. It is not checking whether this transfer was already done before.

This means the operation is not idempotent. Because running it again changes the result again.

Now I try one more case where balance can go negative.

Query
begin;

update accounts
set balance = balance - 2000
where name = 'Alice';

commit;

Here I am trying to deduct more than available balance. Since there is a check constraint balance greater than or equal to zero, PostgreSQL will throw an error and will not allow this update.

So I understand that this rule is enforced by the database itself.

But duplicate transaction is not prevented by database. That should be handled by application logic.

In real systems, they use something called transaction id. Each request will have a unique id. Before processing, system will check if that id is already used. If yes, it will not process again.

So finally what I understood is

Database handles rules like balance should not be negative using constraints.

But problems like duplicate transactions must be handled by the application or transaction design.

CONSISTENCY

Abinaya Dhanraj — Wed, 25 Mar 2026 13:29:12 +0000

Step 1: Check initial data
SELECT * FROM accounts;

Explanation:
Alice has 1000 and Bob has 500.
Both balances are valid (not negative).

Step 2: Try to make balance negative directly
UPDATE accounts
SET balance = -100
WHERE name = 'Alice';

Explanation:
Here I am directly trying to set a negative balance.

What happens:
Query fails

Reason:
There is a constraint CHECK (balance >= 0)

So database itself prevents invalid data.

Step 3: Deduct more than available balance
UPDATE accounts
SET balance = balance - 1500
WHERE name = 'Alice';

Explanation:
Alice has only 1000 but I tried to deduct 1500.

What happens:
Query fails

Reason:
Result becomes negative, so CHECK constraint blocks it

Step 4: Valid deduction
UPDATE accounts
SET balance = balance - 500
WHERE name = 'Alice';

Explanation:
This works because balance remains positive.

Step 5: Using transaction (important case)
BEGIN;

UPDATE accounts
SET balance = balance - 1200
WHERE name = 'Alice';

COMMIT;

Explanation:
Here also it fails before commit.

What happens:
Transaction does not complete

Reason:
Constraint is checked during update

Step 6: Application-level check (manual condition)
UPDATE accounts
SET balance = balance - 1200
WHERE name = 'Alice'
AND balance >= 1200;

Explanation:
Here I added a condition to avoid wrong deduction.

What happens:
No rows updated

Reason:
Condition fails, so query is safe

Final Understanding
Database constraint (CHECK balance >= 0) prevents invalid data
It stops negative values automatically
This is schema-level protection

But,

Checking enough balance before deduction should also be handled in query or application
Otherwise transaction may fail

I tested different updates and observed that database constraints prevent negative balances. I also understood that some validations should be handled in queries or application logic to avoid errors.

ISOLATION

Abinaya Dhanraj — Wed, 25 Mar 2026 13:23:33 +0000

Initial Check
SELECT * FROM accounts;

Explanation:
I checked the initial data.
Alice has 1000 and Bob has 500.

Case 1: READ COMMITTED (default)
Session 1
BEGIN;

UPDATE accounts
SET balance = balance - 800
WHERE name = 'Alice';

Explanation:
I started a transaction and deducted 800 from Alice.
I did not commit, so this change is temporary.

Session 2
BEGIN;

SELECT balance
FROM accounts
WHERE name = 'Alice';

Explanation:
I checked Alice’s balance in another session.
It still shows 1000.

What should happen:
It should show old value

What should not happen:
It should not show updated value (200)

Reason:
Uncommitted data is not visible

Session 2 tries update
UPDATE accounts
SET balance = balance - 500
WHERE name = 'Alice';

Explanation:
This query does not run immediately. It waits.

What should happen:
It should wait

What should not happen:
It should not update instantly

Reason:
Row is locked by session 1

Session 1 commit
COMMIT;

Explanation:
Now the change becomes permanent.
Session 2 will now continue.

Session 2 commit
COMMIT;

Explanation:
Second transaction also completes.

Case 2: REPEATABLE READ
Session 1
BEGIN ISOLATION LEVEL REPEATABLE READ;

UPDATE accounts
SET balance = balance - 300
WHERE name = 'Alice';
Session 2
BEGIN ISOLATION LEVEL REPEATABLE READ;

SELECT balance
FROM accounts
WHERE name = 'Alice';

Explanation:
Session 2 reads the balance once.
Even if session 1 commits later, this value does not change.

What should happen:
Same value should be seen inside transaction

What should not happen:
Value should not change in same transaction

Reason:
Data must remain consistent

Case 3: SERIALIZABLE
Session 1
BEGIN ISOLATION LEVEL SERIALIZABLE;

UPDATE accounts
SET balance = balance - 200
WHERE name = 'Alice';
Session 2
BEGIN ISOLATION LEVEL SERIALIZABLE;

UPDATE accounts
SET balance = balance - 200
WHERE name = 'Alice';
Commit
COMMIT;

Explanation:
When both try to update same data, one may fail.

What should happen:
One transaction may give error

What should not happen:
Both should not succeed if it causes wrong balance

Reason:
Database avoids conflicts

Final understanding

In this experiment, I understood that transactions and isolation levels help to control concurrent operations.
They prevent reading wrong data and avoid incorrect balance updates.
This is important for systems like payment apps where accuracy is very important****