Forem: Wynn TEO

Full-Stack E-Commerce App - Part 1: Project setup

Wynn TEO — Fri, 03 Apr 2026 06:33:53 +0000

Hey! Welcome to Part 1 of this series, where we build a complete, production-ready e-commerce app called ShopFlow — from an empty folder all the way to a live site on AWS.

By the end of this series, ShopFlow will have:

User authentication with JWT tokens
A product catalogue with search powered by Elasticsearch
A shopping cart (stored in Redis) and a full order system
AI features — smart search, a chatbot, and product descriptions generated by AI
Real payments via Stripe and PayPal
Event-driven order processing with Apache Kafka
Deployed on AWS with Kubernetes and a CI/CD pipeline

That sounds like a lot — and it is! But we are going to build it one piece at a time. Each part of this series focuses on one thing, explains why we are doing it, and by the end, you have working code.

In this first part, we just focus on getting everything set up. By the end of this post, your backend and frontend will be running, talking to each other, and you'll understand what every piece does.

This series is aimed at developers who know some coding but maybe haven't built a full-stack app before, or want to see how all these technologies fit together in a real project. If you've followed any beginner tutorials but felt lost when it came to "real-world" apps, this series is for you.

Step 1 — Install the tools

Let's get your machine ready. We need four things: Java 21, Node.js 20, Docker Desktop, and an IDE.

Install Java 25

The best way to install Java is through SDKMAN — a tool that lets you easily switch between Java versions.

On macOS or Linux

Open your terminal and run this:

# Install SDKMAN
curl -s "https://get.sdkman.io" | bash

# Restart your terminal, then install Java 25
sdk install java 25.0.2-tem

# Check it worked
java -version
# You should see: openjdk version "25.0.2"

On Windows

Go to https://adoptium.net and download the "Temurin 25 LTS" Windows installer. Run it, and make sure you tick the option to set JAVA_HOME during setup.

After installing, open Command Prompt and check:

java -version
# openjdk version "25.0.2" ...

Install Node.js 22

We use Node.js to run our React frontend. The cleanest way to install it is through NVM (Node Version Manager) — it lets you easily switch between Node versions on the same machine.

On macOS or Linux

# Install NVM
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

# Restart your terminal, then:
nvm install 22
nvm use 22

# Check
node -v   # v22.x.x
npm -v    # 10.x.x

On Windows

Download nvm-windows from https://github.com/coreybutler/nvm-windows/releases (get nvm-setup.exe). Install it, then open a new terminal:

Install Docker Desktop

Go to https://docker.com/products/docker-desktop and download Docker Desktop for your OS. Install it and start it up. You'll know it's running when you see the whale icon in your menu bar or taskbar.

Check it's working:

docker -v
# Docker version 29.x.x

docker compose version
# Docker Compose version v2.x.x

Install your IDE

For the backend (Java / Spring Boot): Download IntelliJ IDEA Community Edition for free from https://jetbrains.com/idea

For the frontend (React): Download VS Code for free from https://code.visualstudio.com

Once VS Code is open, install these extensions — they make working with React much nicer:

ES7+ React/Redux/React-Native snippets
Prettier — Code formatter
Tailwind CSS IntelliSense
Thunder Client (a Postman alternative built into VS Code — great for testing APIs)

Step 2 — Run MySQL in Docker

Create a new folder anywhere on your computer — call it shopflow. Inside it, create a file called docker-compose.yml and paste this in:

version: "3.8"

services:
  mysql:
    image: mysql:8.0
    container_name: shopflow-mysql
    environment:
      MYSQL_ROOT_PASSWORD: shopflow123
      MYSQL_DATABASE: shopflow_db
      MYSQL_USER: shopflow_user
      MYSQL_PASSWORD: shopflow123
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql
    restart: unless-stopped

volumes:
  mysql_data:

Now open a terminal in that folder and run:

docker compose up -d

# -d means "detached" — runs in the background
# Check it is running:
docker ps

# You should see shopflow-mysql in the list with status "Up"

Let's quickly connect to MySQL to make sure it's working:

docker exec -it shopflow-mysql mysql -u shopflow_user -p
# Type the password: shopflow123

# Once connected:
SHOW DATABASES;
# You should see shopflow_db in the list

EXIT;

Step 3 — Create the Spring Boot backend

Now let's create the backend. We'll use Spring Initializr — a free tool at start.spring.io that generates a ready-to-run Spring Boot project for you.

Generate the project

Go to https://start.spring.io and fill in the settings like this:

Project: Maven
Language: Java
Spring Boot version: 3.3.x (pick the latest stable, not a SNAPSHOT)
Group: com.shopflow
Artifact: backend
Java version: 25

Then click "ADD DEPENDENCIES" and add these:

Spring Web
Spring Data JPA
MySQL Driver
Spring Security
Spring Boot DevTools
Lombok
Validation

Click GENERATE — it downloads a zip file. Extract it into your shopflow/backend folder.

Open it in IntelliJ

Open IntelliJ IDEA. Go to File → Open and navigate to your shopflow/backend folder. IntelliJ will detect it's a Maven project and start downloading dependencies automatically. This takes 1–2 minutes the first time.

Connect it to the database

Open the file src/main/resources/application.properties and replace everything in it with:

# App name
spring.application.name=shopflow-backend

# Database connection
spring.datasource.url=jdbc:mysql://localhost:3306/shopflow_db
spring.datasource.username=shopflow_user
spring.datasource.password=shopflow123
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

# JPA settings
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL8Dialect

# Server port
server.port=8080

Run the app

Find the file BackendApplication.java inside src/main/java/com/shopflow/backend/ and click the green ▶ Run button next to the class name.

Watch the console at the bottom. After a few seconds, you should see:

Tomcat started on port(s): 8080 (http)
Started BackendApplication in 2.847 seconds

Open your browser and go to http://localhost:8080. You'll see a login page — that's Spring Security's default. It means the app is running. We'll replace this with our own auth in Part 2.

Step 4 — Create the React frontend

Now let's set up the frontend. We'll use Vite (pronounced "veet") instead of the old Create React App. Vite starts up in under a second and is way faster during development.

Create the project

Open a new terminal, go to your shopflow folder, and run:

npm create vite@latest frontend -- --template react
cd frontend
npm install

Now let's add the libraries we'll use throughout this series:

# Tailwind CSS — for styling without writing tons of CSS
npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

# React Router — for navigation between pages
npm install react-router-dom

# Axios — for making API calls to our backend
npm install axios

# React Query — for managing server data in React
npm install @tanstack/react-query

Configure Tailwind

Open tailwind.config.js and update the content section:

export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Then open src/index.css and replace everything with just these three lines:

@tailwind base;
@tailwind components;
@tailwind utilities;

Start the React dev server

npm run dev

# You will see:
#   VITE v5.x.x  ready in 300ms
#   ➜  Local:   http://localhost:5173/

Open http://localhost:5173 in your browser. You should see the Vite + React welcome page. That means your frontend is running.

Step 5 — Make the frontend talk to the backend

This is the moment things get real. We're going to make a simple API endpoint in Spring Boot and call it from React.

Create a health check endpoint

In IntelliJ, create a new file: src/main/java/com/shopflow/backend/controller/HealthController.java

package com.shopflow.backend.controller;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.Map;

@RestController
@RequestMapping("/api")
public class HealthController {

    @GetMapping("/health")
    public Map<String, String> health() {
        return Map.of(
            "status", "ok",
            "message", "ShopFlow backend is running!"
        );
    }
}

Let's break down what this does:

@RestController — tells Spring this class handles HTTP requests and returns data (not HTML pages)
@RequestMapping("/api") — all endpoints in this class start with /api
@GetMapping("/health") — when someone calls GET /api/health, run this method

Restart Spring Boot, then open http://localhost:8080/api/health in your browser. You should see:

{
  "status": "ok",
  "message": "ShopFlow backend is running!"
}

Fix CORS so React can call the backend

Right now, if React tries to call the backend, the browser will block it with a CORS error. CORS is a browser security rule that blocks requests from different origins. Our frontend is on port 5173, our backend is on port 8080 — different origins.

Create a new file: src/main/java/com/shopflow/backend/config/CorsConfig.java

package com.shopflow.backend.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
import org.springframework.web.filter.CorsFilter;

@Configuration
public class CorsConfig {

    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOrigin("http://localhost:5173");
        config.addAllowedMethod("*");
        config.addAllowedHeader("*");
        config.setAllowCredentials(true);

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/api/**", config);
        return new CorsFilter(source);
    }
}

Call the API from React

Open src/App.jsx and replace everything with:

import { useState, useEffect } from "react"
import axios from "axios"

function App() {
  const [status, setStatus] = useState("Checking...")

  useEffect(() => {
    axios.get("http://localhost:8080/api/health")
      .then(response => setStatus(response.data.message))
      .catch(() => setStatus("Backend is not running!"))
  }, [])

  return (
    <div className="min-h-screen bg-gray-50 flex items-center justify-center">
      <div className="bg-white rounded-xl shadow-sm border border-gray-100 p-10 text-center">
        <h1 className="text-4xl font-bold text-gray-900 mb-2">ShopFlow</h1>
        <p className="text-gray-400 text-sm mb-4">Full-stack e-commerce app</p>
        <p className="text-gray-500">Backend status:</p>
        <p className="text-green-600 font-semibold mt-1 text-lg">{status}</p>
      </div>
    </div>
  )
}

export default App

Restart Spring Boot (to pick up the CORS config), then open http://localhost:5173. You should see the ShopFlow card with:

"ShopFlow backend is running!"

That's it — your frontend and backend are talking to each other.

Step 6 — Folder structure and Git

Before we go any further, let's organise the project and save our work in Git.

Backend folder structure

This is the structure we'll follow for the whole course. Create these empty folders inside your backend project now so they're ready:

backend/src/main/java/com/shopflow/backend/
├── config/       ← Spring configuration (CORS, Security, etc.)
├── controller/   ← API endpoints
├── service/      ← Business logic
├── repository/   ← Database access
├── model/        ← Entity classes (map to database tables)
│   └── dto/      ← Data Transfer Objects (request/response shapes)
├── security/     ← Auth and JWT
├── exception/    ← Error handling
└── util/         ← Helper utilities

This follows a layered architecture pattern: the request comes in through the Controller, the Controller calls the Service, the Service calls the Repository, the Repository talks to the database. Each layer only talks to the one below it.

Frontend folder structure

frontend/src/
├── api/          ← API call functions (axios)
├── components/   ← Reusable UI pieces (buttons, cards, etc.)
├── pages/        ← Full page components
├── context/      ← React Context (auth state, cart state)
├── hooks/        ← Custom React hooks
└── utils/        ← Helper functions

Set up Git

In your shopflow root folder (the one that contains both backend and frontend), run:

git init
git add .
git commit -m "feat: initial project setup"

Create a .gitignore file in the root:

# Java / Maven
target/
*.class
*.jar

# IntelliJ
.idea/
*.iml

# Node
node_modules/
dist/

# Environment files — NEVER commit these
.env
.env.local

# OS
.DS_Store
Thumbs.db

What's next?

In Part 2 of this series, we build the authentication system. That means:

Designing the user and roles database tables
Building register and login endpoints
Generating JWT tokens so users stay logged in
Protecting routes so only logged-in users can access them
Building the React login page and keeping auth state globally

Authentication is the foundation of the whole app — every other feature depends on it. See you in Part 2.

Essential Java Producer-Consumer Interview Questions

Wynn TEO — Wed, 09 Jul 2025 09:23:09 +0000

In concurrent programming, the Producer-Consumer problem is a classic synchronisation scenario where two entities share a common resource, typically a buffer or queue. The Producer creates data and adds it to the queue, while the Consumer retrieves and processes that data.

In this guide, we’ll:

Implement a thread-safe Producer-Consumer solution in Java.
Fix common pitfalls (race conditions, deadlocks).
Answer the top Java Producer Consumer interview questions.

Problem Overview

In our scenario, the Producer may try to add an item to a full buffer, while the Consumer might attempt to remove an item from an empty buffer. This can lead to synchronisation issues that need to be handled effectively.

Initial Implementation of Shared Buffer (Non-Thread-Safe)

We’ll start by implementing a simple shared buffer using a Queue.

class SharedBuffer {
    private final Queue<Integer> queue = new LinkedList<>();
    private final int capacity;

    public SharedBuffer(int capacity) {
        this.capacity = capacity;
    }

    public void produce(int item) {
        queue.add(item); //Problem: No capacity check
        System.out.println("Produced: " + item);
    }

    public Integer consume() {
        if (queue.isEmpty()) {
            System.out.println("Buffer is empty! Consumer cannot consume.");
            return null;
        } else {
            Integer item = queue.poll();
            System.out.println("Consumed: " + item);
            return item;
        }
    }

    public int size() {
        return queue.size();
    }

    public int getCapacity() {
        return capacity;
    }
}

Next, we’ll create a Producer class that implements the Runnable interface.

class Producer implements Runnable {
    private final SharedBuffer sharedBuffer;

    public Producer(SharedBuffer sharedBuffer) {
        this.sharedBuffer = sharedBuffer;
    }

    @Override
    public void run() {
        for (int i = 0; i < 15; i++) {
            sharedBuffer.produce(i);
            try {
                Thread.sleep(100); // Simulate production time
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            if (sharedBuffer.size() > sharedBuffer.getCapacity()) {
                System.out.println("ERROR: Buffer exceeded capacity! Current size: " + sharedBuffer.size());
            }
        }
    }
}

Now we’ll implement the Consumer class:

class Consumer implements Runnable {
    private final SharedBuffer sharedBuffer;

    public Consumer(SharedBuffer sharedBuffer) {
        this.sharedBuffer = sharedBuffer;
    }

    @Override
    public void run() {
        for (int i = 0; i < 15; i++) {
            sharedBuffer.consume();
            try {
                Thread.sleep(150); // Simulate consumption time
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    }
}

Finally, we will create the main method to run our simulation.

public class ProducerConsumerSimulation {
    public static void main(String[] args) {
        SharedBuffer sharedBuffer = new SharedBuffer(5); // Buffer size of 5
        Thread producerThread = new Thread(new Producer(sharedBuffer));
        Thread consumerThread = new Thread(new Consumer(sharedBuffer));

        producerThread.start();
        consumerThread.start();
    }
}

Run the ProducerConsumerSimulation class. You should see the Producer producing items and the Consumer consuming them. Watch for error messages indicating when the Producer exceeds the buffer capacity.

If we add in one more Consumer thread, we may encounter the same item being consumed twice:

...
Consumed: 2
Consumed: 2
...

Without synchronisation, both the Producer and Consumer can perform actions that lead to inconsistencies in the shared buffer’s state.

Fixed Implementation (Thread-Safe)

To address these issues, we will implement synchronisation techniques using synchronized, wait(), and notify(). This will help us manage access to the shared buffer properly and ensure that the Producer and Consumer operate in harmony.

Revised SharedBuffer Class

Here’s how we can implement synchronisation in the SharedBuffer class and ensure proper communication between the Producer and Consumers:

class SharedBuffer {
    private final Queue<Integer> queue = new LinkedList<>();
    private final int capacity;

    public SharedBuffer(int capacity) {
        this.capacity = capacity;
    }

    // Thread-safe produce()
    public synchronized void produce(int item) throws InterruptedException {
        while (queue.size() == capacity) {
            System.out.println("Buffer is full! Producer waiting...");
            wait(); // Releases lock, waits for consumer to notify
        }
        queue.add(item);
        System.out.println("Produced: " + item);
        notifyAll(); // Wakes up all waiting consumers
    }

    public synchronized Integer consume() throws InterruptedException {
        while (queue.isEmpty()) {
            System.out.println("Buffer is empty! Consumer waiting...");
            wait(); // Releases lock, waits for producer to notify
        }
        Integer item = queue.poll();
        System.out.println(Thread.currentThread().getName() + " consumed item " +item+ ".");
        notifyAll(); // Wakes up all waiting producers
        return item;
    }

    public synchronized int size() {
        return queue.size();
    }

    public int getCapacity() {
        return capacity;
    }
}

class Producer implements Runnable {
    private final SharedBuffer sharedBuffer;

    public Producer(SharedBuffer sharedBuffer) {
        this.sharedBuffer = sharedBuffer;
    }

    @Override
    public void run() {
        for (int i = 0; i < 10; i++) {
            try {
                sharedBuffer.produce(i);
                Thread.sleep(100); // Simulate production time
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    }
}

class Consumer implements Runnable {
    private final SharedBuffer sharedBuffer;

    public Consumer(SharedBuffer sharedBuffer) {
        this.sharedBuffer = sharedBuffer;
    }

    @Override
    public void run() {
        for (int i = 0; i < 10; i++) {
            try {
                sharedBuffer.consume();
                Thread.sleep(200); // Simulate consumption time
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    }
}

public class Main {
    public static void main(String[] args) {
        SharedBuffer sharedBuffer = new SharedBuffer(5); // Buffer size of 5
        Thread producerThread = new Thread(new Producer(sharedBuffer));
        Thread consumerThread = new Thread(new Consumer(sharedBuffer));
        Thread consumer2Thread = new Thread(new Consumer(sharedBuffer));

        producerThread.start();
        consumerThread.start();
        consumer2Thread.start();
    }
}

With this implementation, you will see output that includes the names of the Consumer threads, like this:

Common Interview Questions

1. Why should we check the waiting conditions on the while loop instead of the if block?

Condition Re-evaluation:
When a thread wakes up from waiting (after a notify()), it does not automatically mean the condition it was waiting for has changed. Using while ensures the thread checks the condition again.
If we use if, there’s a risk that the thread proceeds without re-checking the condition, leading to potential errors.

Spurious Wakeups:
Threads can wake up from waiting due to reasons other than a notify(), known as “spurious wakeups.” Using while helps protect against this by forcing the thread to re-evaluate the condition. Always use a loop (while) to check the condition after waking up.

2. Why should we use the notifyAll() rather than the notify() method?

Waking Up All Waiting Threads:
notifyAll() wakes up all threads that are waiting on the object’s monitor, while notify() only wakes one. This is particularly important in scenarios with multiple producers and consumers.

Avoiding Deadlocks:
Using notifyAll() can help prevent situations where a single notify() might not wake the right thread, potentially leading to deadlocks or threads waiting indefinitely.

Fairness:
In a multi-threaded environment, using notifyAll() ensures that all waiting threads get a chance to proceed when the condition changes, promoting fairness.

Complex Conditions:
If multiple threads are waiting for different conditions (e.g., multiple consumers waiting for items and multiple producers waiting for space), notifyAll() ensures that all threads can recheck their conditions after being woken up.

3. Why wait() method should be called from a synchronized method or block?

Intrinsic Lock Requirement:
The wait(), notify(), and notifyAll() methods are designed to be used with the intrinsic lock (or monitor) of the object on which they are called. When a thread calls wait(), it must own the lock on that object.
Releasing the Lock:

When a thread calls wait(), it releases the lock on the object and enters the waiting state. This allows other threads to acquire the lock and make progress. If wait() were called without holding the lock, there would be no lock to release, leading to IllegalMonitorStateException exceptions.

Ensuring Atomicity:
The synchronized keyword ensures that the thread calling wait() holds the intrinsic lock of the object. By calling wait() within a synchronized block, you ensure that the state check and the call to wait() are performed atomically. This prevents race conditions where the state might change between the check and the wait call.

4. Why wait() and notify() methods are defined in java.lang.Object class instead of Thread?

Threads need to acquire a lock (or monitor) on an object to enter a synchronized block or method. Threads do not need to know which specific thread currently holds the lock. They only care whether the lock is available. If the lock is not available (held by another thread), the thread will wait until the lock is released.

Coordination with wait() and notify():
A thread that calls wait() on an object releases the lock and waits until another thread calls notify() or notifyAll() on the same object.
This allows threads to coordinate without knowing the details of other threads.

Intrinsic Lock Mechanism:
Every Java object has an intrinsic lock associated with it, also known as a monitor. The wait(), notify(), and notifyAll() methods are used to coordinate thread activity based on this monitor.
By defining these methods in the Object class, Java allows any object to be used as a lock for synchronisation purposes, not just threads.

Object-Level Synchronisation:
Synchronisation in Java is based on object-level locks. When a thread enters a synchronized block, it acquires the lock of the object that is used to synchronise the block. The wait() method releases this lock and puts the thread into a waiting state. The notify() and notifyAll() methods wake up threads that are waiting on this lock.

These methods need to be in the Object class so that any object can be the target of synchronisation.

5. What happens if a thread throws Exception inside a synchronized block?

When a thread enters a synchronized block or method, it acquires the lock on the synchronized object. If an exception is thrown inside the synchronized block, the thread exits the block. Exiting the block, whether normally or due to an exception, causes the lock to be released. Once the lock is released, other threads waiting for the lock can acquire it and proceed with their execution.

6. What is the difference between wait() and sleep()?

wait(): Releases the lock and allows other threads to acquire it; should be called from a synchronized context.
sleep(): Does not release the lock and simply pauses the current thread for a specified duration.

7. What is the purpose of the volatile keyword in Java?

Definition: Indicates that a variable’s value will be modified by different threads.
Usage: Ensures visibility of changes to variables across threads, preventing caching issues.

For a more detailed explanation and full source code, you can visit the following link

Spring @Transactional Rollback Handling

Wynn TEO — Thu, 03 Aug 2023 12:43:53 +0000

Spring @Transactional Rollback Handling

By default, the spring boot transaction is auto-commit. Every single SQL statement is in its own transaction and will commit after execution. Take a look at the below example, the product is inserted into the database even though an exception has been raised.

public void createProduct() {  
    System.out.println("------ createProduct ------");
    Product prod = new Product();
    prod.setDescription("This is an example with runtime exception but no rollback.");
    prod.setPrice(10);
    prod.setTitle("First Product");
    productRepository.save(prod);
    System.out.println("First Product inserted.");

throw new RuntimeException();
}

This shouldn’t be the case. In some scenarios, multiple transactions are run in a logical unit of code. All the transactions should only commit when there is no exception occurring in between.

In Spring Boot, when @Transactional annotation is used, Spring Boot implicitly creates a proxy that will be creating a connection to the database. A transaction will be started and committed after the code has been executed errorless. Otherwise, it will roll back the changes if an exception occurred.

**import** **java.sql.Connection**;

**Connection** conn = dataSource.getConnection(); 

**try** (connection) {

 *   // execute some SQL statements...*

 *   *// commit transaction
    conn.commit();

} **catch** (**SQLException** e) {
    conn.rollback();
}

Example 1

In this example, we added @Transactional annotation to roll back the transaction if the exception occurred.

**@Transactional**
public void createProduct() {  
    System.out.println("------ createProduct ------");
    Product prod = new Product();
    prod.setDescription("This is an example with runtime exception and transactional annotation.");
    prod.setPrice(10);
    prod.setTitle("Second Product");
    productRepository.save(prod);
    System.out.println("Second Product inserted.");

    throw new RuntimeException();
}

The above example proves that the @Transactional annotation can roll back the transaction if the exception occurs. Take note, Spring only rolled back on unchecked exceptions by default.

Example 2a

This example shows that the checked exception will not be rolled back even though we have specified the **@Transactional **annotation.

@Transactional
public void createProduct() throws Exception{  
    System.out.println("------ createProduct ------");
    Product prod = new Product();
    prod.setDescription("This is an example with checked exception and transactional annotation.");
    prod.setPrice(10);
    prod.setTitle("Second Product");
    productRepository.save(prod);
    System.out.println("Second Product inserted.");
    throw new SQLException();
}

Example 2b

To roll back checked exceptions, we need to specify the rollbackFor

@Transactional( **rollbackFor** = SQLException.class)
public void createProduct() throws Exception{  
    System.out.println("------ createProduct ------");
    Product prod = new Product();
    prod.setDescription("This is an example with checked exception and transactional annotation with rollbackFor.");
    prod.setPrice(10);
    prod.setTitle("Example 2b Product");
    productRepository.save(prod);
    System.out.println("Example 2b inserted.");
    throw new SQLException();
}

We see that the transaction has rolled back successfully.

Example 3

In this example, we added the try-catch block to see if the rollback still working.

@Transactional
public void createProduct() {
    try {
        System.out.println("------ createProduct ------");
        Product prod = new Product();
        prod.setDescription("This is an example with runtime exception, transactional annotation and try catch.");
        prod.setPrice(10);
        prod.setTitle("Example 3 Product");
        productRepository.save(prod);
        System.out.println("Example 3 Product inserted.");
        throw new RuntimeException();
    }catch (Exception e){
        System.out.println("Here we catch the exception.");
    }
}

It won’t work. This happened because we manually caught the exception and handle it. Therefore the current transaction is being executed normally and committed.

Example 4

What about a nested transaction? From the example below, the createProduct()*and *createOrder() methods will insert a record into the database. The createOrder() method has thrown a runtime exception. Both methods have been annotated with the **@Transactional **annotation.

//ProductController.java
@Transactional
public void createProduct() {
    System.out.println("------ createProduct ------");
    Product prod = new Product();
    prod.setDescription("This is createProduct method.");
    prod.setPrice(10);
    prod.setTitle("Create Product");
    productRepository.save(prod);
    orderController.createOrder();
}

//OrderController.java
@Transactional
public void createOrder() {
    System.out.println("------ createOrder ------");
    Order order = new Order();
    order.setTitle("Create Order");
    order.setDescription("This is createOrder method with runtime exception");
    orderRepository.save(order);  
    throw new RuntimeException("Create Order RuntimeException");
}

createProduct()*and *createOrder() transactions were rolled back. Even though the runtime exception has happened in the createOrder() method. However, because it doesn’t handle the exception, this led to the createProduct() transaction also rollback.

Example 5

Let’s add in the try-and-catch block to handle the runtime exception in the createProduct() method.

//ProductController.java
@Transactional
public void createProduct() {
    System.out.println("------ createProduct ------");
    Product prod = new Product();
    prod.setDescription("This is createProduct method.");
    prod.setPrice(10);
    prod.setTitle("Create Product");
    productRepository.save(prod);
    try{
        orderController.createOrder();
    }catch (RuntimeException e){
        System.out.println("Handle " + e.getMessage());
    }
}

//OrderController.java
@Transactional
public void createOrder() {
    System.out.println("------ createOrder ------");
    Order order = new Order();
    order.setTitle("Create Order");
    order.setDescription("This is createOrder method with runtime exception");
    orderRepository.save(order);  
    throw new RuntimeException("Create Order RuntimeException");
}

Arg? Both records have been rollback. Why? At the same time, we also noticed the exception error.

org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only

@Transactional has a parameter called **Propagation. **Propagation will define the transaction boundary. Spring will start and end the transaction according to the propagation setting. By default, propagation is set to **REQUIRED. **So, if there is an active transaction, Spring will consume it instead of creating a new transaction. Therefore, in the above scenario, even though we have caught the exception on the outer method, the transaction was still rolling back.

Example 6

Use Propagation **REQUIRES_NEW, **this will force spring to create a subtransaction.

@Transactional
public void createProduct() {
    System.out.println("------ createProduct ------");
    Product prod = new Product();
    prod.setDescription("This is createProduct method.");
    prod.setPrice(10);
    prod.setTitle("Create Product");
    productRepository.save(prod);
    try{
        orderController.createOrder();
    }catch (RuntimeException e){
        System.out.println("Handle " + e.getMessage());
    }
}

@Transactional(propagation=Propagation.REQUIRES_NEW)
public void createOrder() {
    System.out.println("------ createOrder ------");
    Order order = new Order();
    order.setTitle("Create Order");
    order.setDescription("This is createOrder method with runtime exception");
    orderRepository.save(order);  
    throw new RuntimeException("Create Order RuntimeException");
}

The product record was written into the database, and the order record was rolled back.

Example 7

What if we never use try and catch block in the outer method, and an exception has happened in the inner method? Will the outer transaction still commit?

@Transactional
public void createProduct() {
    System.out.println("------ createProduct ------");
    Product prod = new Product();
    prod.setDescription("This is createProduct method.");
    prod.setPrice(10);
    prod.setTitle("Create Product");
    productRepository.save(prod);
    orderController.createOrder();
}

@Transactional(propagation=Propagation.REQUIRES_NEW)
public void createOrder() {
    System.out.println("------ createOrder ------");
    Order order = new Order();
    order.setTitle("Create Order");
    order.setDescription("This is createOrder method with runtime exception");
    orderRepository.save(order);  
    throw new RuntimeException("Create Order RuntimeException");
}

We see that both transactions have been rolled back. Because the inner transaction threw an exception, the outer transaction detected the exception and it hasn’t been handled. Therefore, the outer transaction has been rolled back.

Example 8

Let’s see if the exception has happened in the outer method instead.

@Transactional
public void createProduct() {
    System.out.println("------ createProduct ------");
    Product prod = new Product();
    prod.setDescription("This is createProduct method.");
    prod.setPrice(10);
    prod.setTitle("Create Product with runtime");
    productRepository.save(prod);
    orderController.createOrder();
    throw new RuntimeException("Create Product RuntimeException");
}

@Transactional(propagation=Propagation.REQUIRES_NEW)
public void createOrder() {
    System.out.println("------ createOrder ------");
    Order order = new Order();
    order.setTitle("Create Order with propagation required_new");
    order.setDescription("This is createOrder method.");
    orderRepository.save(order);  
}

We see that the inner transaction has been committed successfully due to the Propagation.REQUIRES_NEW. This forces the Spring to handle the query in subtransaction. Once it is completed the outer transaction resumed, and an exception happened at this moment, so it rolled back.

Additional Notes

To take note, if both methods are in the same class, the @Transactional annotation will not take place. It will always be treated as one transaction, so even if we specified the Propagation.REQUIRES_NEW, it won’t work. At the very beginning, we talked about Spring creating a proxy when seeing annotation @Transactional. When you are calling the internal method, it will bypass the proxy.

Thanks for reading!

Forem: Wynn TEO

Full-Stack E-Commerce App - Part 1: Project setup

Step 1 — Install the tools

Install Java 25

On macOS or Linux

On Windows

Install Node.js 22

On macOS or Linux

On Windows

Install Docker Desktop

Install your IDE

Step 2 — Run MySQL in Docker

Step 3 — Create the Spring Boot backend

Generate the project

Open it in IntelliJ

Connect it to the database

Run the app

Step 4 — Create the React frontend

Create the project

Configure Tailwind

Start the React dev server

Step 5 — Make the frontend talk to the backend

Create a health check endpoint

Fix CORS so React can call the backend

Call the API from React

Step 6 — Folder structure and Git

Backend folder structure

Frontend folder structure

Set up Git

What's next?

Top Asynchronous JavaScript Interview Questions (2025)

Introduction

What Makes JavaScript Asynchronous?

The Call Stack Explained

The Problem with Synchronous Code

Asynchronous Callbacks – The Solution

1: How Does setTimeout Work?

2: What Happens with setTimeout(fn, 0)?

3: Multiple setTimeout Calls

4: What About Nested Promises?

5: Error Handling in Async Code

Conclusion

Essential Java Producer-Consumer Interview Questions

Problem Overview

Initial Implementation of Shared Buffer (Non-Thread-Safe)

Fixed Implementation (Thread-Safe)

Revised SharedBuffer Class

Common Interview Questions

1. Why should we check the waiting conditions on the while loop instead of the if block?

2. Why should we use the notifyAll() rather than the notify() method?

3. Why wait() method should be called from a synchronized method or block?

4. Why wait() and notify() methods are defined in java.lang.Object class instead of Thread?

5. What happens if a thread throws Exception inside a synchronized block?

6. What is the difference between wait() and sleep()?

7. What is the purpose of the volatile keyword in Java?

Spring @Transactional Rollback Handling

Spring @Transactional Rollback Handling

Example 1

Example 2a

Example 2b

Example 3

Example 4

Example 5

Example 6

Example 7

Example 8

Additional Notes