Forem: omoogun olawale

Database Transaction Leak

omoogun olawale — Fri, 16 Jan 2026 02:08:15 +0000

Introduction

We often talk about memory leaks, but there is another silent performance killer in backend development: Database Transaction Leaks.

I recently spent time debugging a legacy codebase where a specific module’s tests passed perfectly in isolation but failed consistently when run as part of the full suite. The culprit? A "Database connection timeout" that I initially dismissed as a fluke. Here is how I discovered that our code was "leaking" database connections and how we fixed it.

The Symptom: The "Loner" Test

In isolation, my User module tests were green. However, when run alongside fifty other tests, they would suddenly time out.

I realized that the database wasn't actually slow; it was exhausted. Previous tests were opening transactions and never closing them, holding onto connections from the pool until there were none left for the subsequent tests.

The Culprit #1: The Early Return Trap

In our legacy controllers, many functions relied on manual transaction management. I found several instances where an "early return" was triggered, but the developer forgot to close the transaction before exiting the function.

The Buggy Code:

JavaScript

const t = await startTransaction();
 try {
   if (someCondition) {
     // Early return! The transaction 't' stays open forever 
     // until the database or server kills the process.
     return { status: 400, message: "Invalid Request" };
   }

   await t.commit();
 } catch (e) {
   await t.rollback();
 }

The Culprit #2: Shared Transaction Ownership

The second issue was more subtle: Nested Transaction Suicide. A parent function would create a transaction and pass it to a child function. The child function would then commit or rollback the transaction itself. When control returned to the parent, the parent would try to commit a transaction that was already closed.

The Buggy Code:

JavaScript


async function childFunction(t) {
  try {
    const data = await db.create({}, { transaction: t });
    await t.commit(); // Child closes the transaction
    return data;
  } catch (e) {
    await t.rollback();
    throw e;
  }
}

async function parentScope() {
  const t = await startTransaction();
  try {
    const data = await childFunction(t);
    await t.commit(); // Error! The transaction is already finished.
    return data;
  } catch (e) {
    await t.rollback();
  }
}

Why didn't this break Production?
You might wonder: if we were leaking connections, why didn't the production server crash every hour?

The answer was PM2. Our production environment used PM2 to manage the Node.js processes. When the connection pool became exhausted and the app began to hang or crash, PM2 would automatically restart the instance. This cleared the "leaked" connections, acting as a temporary (and dangerous) bandage. Users just perceived this as "the app is occasionally slow."

The Solution: Proper Transaction Management

1. Explicit Lifecycle Management

Always ensure every possible code path (especially early returns) handles the transaction.

JavaScript

const t = await startTransaction();
try {
  if (someCondition) {
    await t.rollback(); // Always clean up before returning!
    return { status: 400 };
  }
  await t.commit();
} catch (e) {
  await t.rollback();
}

2. The "Single Owner" Principle

A good rule of thumb: The function that creates the transaction should be the one to close it. If you pass a transaction to a child function, the child should use it but never commit or rollback itself.

JavaScript

async function childFunction(t) {
  // Use the transaction 't', but don't commit/rollback here
  return await db.create({}, { transaction: t });
}

async function parentScope() {
  const t = await startTransaction();
  try {
    await childFunction(t);
    await t.commit(); // Only the creator manages the lifecycle
  } catch (e) {
    await t.rollback();
  }
}

Conclusion

By fixing these transaction leaks, our test suite went from flaky and slow to stable and fast. If your tests pass individually but fail in a group, don't ignore those "Connection Timeout" errors—you might just have a leak in your database logic.

Golang: Generics in Go

omoogun olawale — Sat, 26 Apr 2025 12:17:44 +0000

Hi devs,
I will be writing an interesting article on how generics helped me solve a challenging problem while I was working on a simple REST API project built with GoLang using the gin framework.

The problem

/* model.go */
type LoginAuth struct {
    USERNAME string `bson:"username" json:"username" validate:"required,min=1"`
    PASSWORD string `bson:"username" json:"password" validate:"required,min=4"`
}

/* controller.go */
var user model.LoginAuth
if err := c.BindJSON(&user); err != nil {
  c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
  return
}

The code snippet above is from an authentication controller.
My goal is to reuse this code snippet below with other resources's controllers with different types.

e.g Comment controller with model.Comment type

var user model.LoginAuth
if err := c.BindJSON(&user); err != nil {
  c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
  return
}

The Solution

func bindJSONData[T any](c *gin.Context) (T, bool) {
    var data T
    if err := c.BindJSON(&data); err != nil {
        utils.AbortResponse(c, utils.Reponse{StatusCode: http.StatusUnprocessableEntity, Success: false, Message: err.Error(), Data: nil})
        return *new(T), false
    }
    return data, true
}

I created a generic function bindJSONData that takes a type parameter T.
This T represents the struct type we want to bind the JSON data to.
Inside the function, I declared a variable data of type T.
The c.BindJSON(&data) call remains the same, but now it dynamically binds to the type specified by T.
The function now returns both the bound data of type T and a boolean indicating success. This makes the calling code cleaner.
If binding fails, it returns the zero value of type T and false.

Hope this post helps. Feel free to leave a comment on this post I will be in the comment section.

MongoDB: Startup replica sets with a config file

omoogun olawale — Tue, 31 Dec 2024 12:43:17 +0000

Hi Devs,
In the previous post, we talked about setting up replica sets. Kindly go through the post for setting up replica set.
What we will be discussing today will be starting up each member of our replica sets with a config file

This post will be as brief as possible.

In our previous post, we create replica sets with 3 members. We will only work with one of them while you replicate the steps below for other members.

Create a config file

Change to the directory where we created our replica sets. In our case it was in our home directory

cd replicas

cd db1

What the command does is change our working directory to first member of the replica set. We will create the config file for this member here

touch mongo.conf

What the command does is to create a filename mongo with extension .conf.
Kindly note the name of the file is up to you. However, the extension must be .conf
Past the following into the file

replication:
  replSetName: "rs0"
net:
  bindIp: 127.0.0.1
  port: 27018
systemLog:
  destination: file
  path: "./logs/log1.log"
  logAppend: true
storage:
  dbPath: "./data/db1"
  journal:
    enabled: true
security:
  authorization: "disabled"

Note
Make sure what is pasted follows yaml convention

If you followed the previous post you would notice the replica set id we used was rs0 that explains the replSetName in the config file
port: the port this member listens from. In this case it is 27018 for the first member
systemLog: The path value where you want to write the logs to. You can disable it if you don't to write it to a log. It will output it on your console
storage: The dbPath value is the data directory of the member in the replica sets. For this member it resides in the specified path above

Kindly check the previous post for how we created the logs and data directory for each member in the set

Repeat the step above for other members in the set

Connect to the member's instance

Open 3 tabs on your terminal
make sure the working directory on the terminal is the directory where all these members were created. In our case it is replicas
First Terminal

mongod --config db1/mongo.conf

The command above will start the mongo instance for the first member of the set. You will not see any logs on the console. This is because the logs are written to its log file.

Second terminal

mongod --config db2/mongo.conf

Third Terminal

mongod --config db3/mongo.conf

Open a fourth terminal to connect to mongo interactive shell for the first memeber

  mongosh --port 27018

If you followed the previous post you would notice that is the port we listened to the first member of the set

Feel to ask any questions.

MongoDB: How to setup replica sets

omoogun olawale — Tue, 31 Dec 2024 12:09:36 +0000

Hi devs
Today I am going to write about an interesting topic in mongodb which is How to setup replica sets on your localhost machine for development only

Setup replica sets folder

mkdir replicas

What the command above does is create a directory/folder named replicas in my home directory. This directory will hold the number of replica sets we want to have
Note: I am using mac for this tutorial

cd replicas

What the command above does is change your working directory to replicas. Inside this directory is where we will create directories for our replica sets

mkdir db1

mkdir db2

mkdir db3

What the command above does is create 3 different directories for the members of our replica sets. 3 members will suffice for this tutorial. Feel free to create as many as possible.
Kindly note replica sets must have at least 2 members

Setup data folders for replica sets

The next phase is create the data directory for each member of the sets

mkdir data

cd data

What the commands above does is create the data directory and make it the working directory.

mkdir db1

mkdir db2

mkdir db3

What the command above does is to create 3 directories for each member of the sets. We are creating 3 because we have 3 members in our case.
Kindly note the name of the folder/directory is totally up to you

Setup replica sets log folders

The next phase is create the logs directory for each member of the sets

cd ..

what the command above does is change the working directory to replicas

mkdir logs

cd logs

What the command above does is create the logs directory and make it the working directory.

touch log1.log

touch log2.log

touch log3.log

What the command above does is create 3 log files for each member of the sets. We are creating 3 because of we have 3 members in our case.
Kindly note the name of the files is totally up to you

Start instance of each member

What we want to do at this stage is start the instance of the replica set members

Open 3 tabs on your MacOS terminal or on windows open 3 command prompts

Make sure the working directories of these terminals are replicas

First terminal:

mongod --replSet rs0 --port 27018 --bind_ip localhost --dbpath  db1

Second terminal:

mongod --replSet rs0 --port 27019 --bind_ip localhost --dbpath  db2

Third terminal:

mongod --replSet rs0 --port 27010 --bind_ip localhost --dbpath  db3

rs0: replica set id

Initiate members

What we did above is startup instance of each member of the replica sets
Open a fourth terminal

bash
mongosh --port 27018

what the command above does is connect to interactive mongo shell of the first member of the replica sets. This is where we will initiate the members

rsConf = {
  _id: "rs0",
  members: [
     {_id: 0, host: "localhost:27018"},
     {_id: 0, host: "localhost:27018"},
     {_id: 0, host: "localhost:27018"},
   ]
 }

Hit enter

 rs.initiate(rsConf)

Hit enter

Voila!!!!. You have successfully initiated replica sets.

To verify if the initiation was successful. Enter the command below on your terminal

rs.status()

How to start replica sets with config file

You should see an object of the replica sets with its members

Feel free to ask questions.

References

https://vishalrana9915.medium.com/how-to-create-replica-sets-in-mongodb-eaaa7b967b43
https://hevodata.com/learn/mongodb-replica-set-3-easy-methods/

[Boost]

omoogun olawale — Thu, 26 Dec 2024 11:12:02 +0000

Tailwind: Combine custom css with @components directive

omoogun olawale ・ Dec 19 '24

#tailwindcss #css #react #nextjs

Tailwind: Combine custom css with @components directive

omoogun olawale — Thu, 19 Dec 2024 11:41:22 +0000

Hi devs,
I came across a challenge that I want to share and how I solved it. These articles will help other devs like me who ran into the same issue.

The challenge

My challenge was to create a reusable component with tailwind components directive while I applied my custom CSS as seen below. It seems impossible at first and challenging.

My custom css

.text-shadow: {
  text-shadow: none
}

.tap-highlight: {
  --webkit-tap-highlight-color: transparent
}

tailwind component directive

@layer components {
  @apply text-shadow tap-highlight bg-red-900 rounded-full text-base
}

The solution

After searching the internet for a solution I could not get it to work. So I had an idea to add my utility class through addUtilities function from tailwind plugin

const plugin = require("tailwindcss/plugin");
---- other code goes here
  plugins: [
    plugin(function ({ addUtilities }) {
      addUtilities({
        ".text-shadow": {
          textShadow: "none",
        },
        ".tap-highlight": {
          WebkitTapHighlightColor: "transparent",
        },
      });
    }),
  ],

What I did was to import tailwindcss/plugin and add my utility classes as seen above. Voila it works

Thanks for reading! Let me know in the comments if you have any questions.