مقدمه

در توسعه نرم‌افزارهای حرفه‌ای، فقط ذخیره کردن داده در دیتابیس کافی نیست. مسئله مهم‌تر این است که داده‌ها درست، کامل، سازگار و قابل اعتماد ذخیره شوند. تصور کنید در یک فروشگاه اینترنتی، کاربر سفارشی ثبت می‌کند. در این فرآیند باید سفارش ایجاد شود، آیتم‌های سفارش ذخیره شوند، موجودی کالا کم شود، پرداخت ثبت شود، فاکتور ساخته شود و شاید پیامک یا ایمیل ارسال گردد. حالا اگر سفارش ثبت شود اما موجودی کالا کم نشود، یا پرداخت موفق باشد اما فاکتور ساخته نشود، سیستم با داده‌های ناقص و ناسازگار روبه‌رو می‌شود.

اینجاست که مفهوم Transaction دیتابیس اهمیت پیدا می‌کند. Transaction یا تراکنش دیتابیس مکانیزمی است که چند عملیات مرتبط را به‌عنوان یک واحد کاری در نظر می‌گیرد. نتیجه این واحد کاری باید کامل باشد؛ یعنی یا همه عملیات‌ها با موفقیت انجام شوند، یا هیچ‌کدام اثر نهایی روی دیتابیس نگذارند.

در مستندات رسمی PostgreSQL، تراکنش‌ها به‌عنوان مفهومی بنیادی در همه سیستم‌های دیتابیس معرفی شده‌اند و نکته اصلی آن‌ها این است که چند مرحله را در قالب یک عملیات «همه یا هیچ» بسته‌بندی می‌کنند. مطالعه توضیح رسمی PostgreSQL درباره Transactions

این مفهوم برای شرکت‌های تولید نرم‌افزار بسیار مهم است؛ چون بسیاری از پروژه‌های سازمانی، مالی و فروشگاهی با داده‌هایی سروکار دارند که کوچک‌ترین ناسازگاری در آن‌ها می‌تواند باعث خطای حسابداری، نارضایتی مشتری، از بین رفتن اعتماد کاربر یا حتی خسارت مالی شود.

در این مقاله، به‌صورت کامل و فنی بررسی می‌کنیم Transaction دیتابیس چیست، چرا اهمیت دارد، اصول ACID چه هستند، Commit و Rollback چه نقشی دارند، Isolation Level چگونه روی همزمانی اثر می‌گذارد، Deadlock چیست، در Laravel چگونه از Transaction استفاده می‌شود و در پروژه‌های واقعی چه Best Practiceهایی باید رعایت شود. 🚀

Transaction دیتابیس چیست؟

Transaction دیتابیس مجموعه‌ای از یک یا چند عملیات دیتابیس است که باید به‌صورت یک واحد منطقی اجرا شوند. این عملیات می‌توانند شامل INSERT، UPDATE، DELETE یا حتی چند Query پیچیده باشند. هدف Transaction این است که دیتابیس بعد از پایان عملیات در یک وضعیت درست و سازگار باقی بماند.

مثال ساده بانکی را در نظر بگیرید. انتقال پول از حساب کاربر A به حساب کاربر B شامل دو عملیات است:

1. کم کردن مبلغ از حساب A
2. اضافه کردن همان مبلغ به حساب B

اگر عملیات اول انجام شود اما عملیات دوم به دلیل خطا انجام نشود، پول از حساب A کم شده اما به حساب B اضافه نشده است. این یک خطای جدی در سازگاری داده است. با Transaction، این دو عملیات در یک واحد قرار می‌گیرند؛ اگر هر دو موفق باشند، تغییرات ذخیره می‌شوند؛ اما اگر یکی خطا بدهد، همه چیز به حالت قبل بازمی‌گردد.

نمونه SQL ساده:

START TRANSACTION;

UPDATE accounts
SET balance = balance - 100000
WHERE id = 1;

UPDATE accounts
SET balance = balance + 100000
WHERE id = 2;

COMMIT;

اگر در میانه کار خطایی رخ دهد:

ROLLBACK;

یعنی تغییرات انجام‌شده در آن تراکنش لغو می‌شوند.

چرا Transaction در نرم‌افزارهای شرکتی مهم است؟

در نرم‌افزارهای واقعی، معمولاً یک عملیات کاربر فقط یک Query ساده نیست. بیشتر عملیات‌های مهم شامل چند مرحله هستند. برای مثال:

در پروژه‌های شرکتی، Transaction فقط یک قابلیت فنی نیست؛ بلکه بخشی از اعتمادپذیری محصول است. وقتی مشتری از یک نرم‌افزار مالی، CRM، ERP یا فروشگاه آنلاین استفاده می‌کند، انتظار دارد داده‌ها همیشه قابل اعتماد باشند.

مفهوم ACID در Transaction

یکی از پایه‌ای‌ترین مفاهیم در بحث Transaction، مدل ACID است. ACID مجموعه‌ای از چهار اصل برای اطمینان از قابل اعتماد بودن تراکنش‌هاست:

A = Atomicity
C = Consistency
I = Isolation
D = Durability

مستندات رسمی MySQL برای InnoDB توضیح می‌دهد که مدل ACID مجموعه‌ای از اصول طراحی دیتابیس است که روی جنبه‌های مهم قابلیت اعتماد برای داده‌های تجاری و برنامه‌های Mission-Critical تمرکز دارد. مطالعه مستندات رسمی MySQL درباره InnoDB و ACID

1. Atomicity؛ اتمی بودن

Atomicity یعنی عملیات‌های داخل یک Transaction باید مثل یک واحد غیرقابل تقسیم رفتار کنند. یا همه انجام می‌شوند یا هیچ‌کدام.

مثال:

START TRANSACTION;

INSERT INTO orders (user_id, total_price) VALUES (1, 500000);
INSERT INTO payments (order_id, amount, status) VALUES (10, 500000, 'paid');

COMMIT;

اگر ثبت پرداخت خطا بدهد، ثبت سفارش هم نباید نهایی شود.

2. Consistency؛ سازگاری

Consistency یعنی دیتابیس قبل و بعد از Transaction باید قوانین معتبر خود را حفظ کند. برای مثال:

• موجودی حساب نباید منفی شود.
• سفارش بدون کاربر معتبر نباید ثبت شود.
• مجموع بدهکار و بستانکار سند حسابداری باید برابر باشد.
• آیتم سفارش باید به محصول موجود متصل باشد.

Transaction به‌تنهایی همه قوانین تجاری را تضمین نمی‌کند، اما کمک می‌کند اجرای چند عملیات مرتبط باعث ناسازگاری نشود.

3. Isolation؛ ایزوله بودن

Isolation یعنی تراکنش‌های همزمان نباید به شکل خطرناک روی هم اثر بگذارند. وقتی چند کاربر همزمان خرید می‌کنند، پرداخت انجام می‌دهند یا موجودی کالا را تغییر می‌دهند، دیتابیس باید رفتار قابل پیش‌بینی داشته باشد.

برای مثال، اگر فقط یک عدد از یک کالا باقی مانده باشد و دو کاربر همزمان سفارش ثبت کنند، بدون کنترل درست ممکن است هر دو سفارش موفق شوند. Isolation و Locking برای کنترل این وضعیت استفاده می‌شوند.

4. Durability؛ ماندگاری

Durability یعنی وقتی Transaction با موفقیت Commit شد، تغییرات باید پایدار باشند. حتی اگر بعد از Commit سیستم دچار مشکل شود، دیتابیس باید بتواند داده‌های تأییدشده را حفظ کند.

در MySQL، موتور InnoDB با امکاناتی مثل Commit، Rollback و Crash Recovery برای محافظت از داده‌ها طراحی شده است. مستندات رسمی Oracle درباره InnoDB نیز اشاره می‌کند که عملیات DML در InnoDB از مدل ACID پیروی می‌کنند و تراکنش‌ها با قابلیت Commit، Rollback و Crash-Recovery از داده کاربر محافظت می‌کنند. مطالعه معرفی رسمی InnoDB در MySQL

Commit و Rollback چیست؟

دو مفهوم بسیار مهم در Transaction، عبارت‌اند از Commit و Rollback.

Commit چیست؟

COMMIT یعنی تمام تغییرات انجام‌شده در Transaction تأیید و دائمی شوند.

START TRANSACTION;

UPDATE products
SET stock = stock - 1
WHERE id = 5;

INSERT INTO orders (product_id, quantity)
VALUES (5, 1);

COMMIT;

بعد از Commit، تغییرات نهایی شده‌اند.

Rollback چیست؟

ROLLBACK یعنی تغییرات انجام‌شده در Transaction لغو شوند و دیتابیس به وضعیت قبل از شروع تراکنش برگردد.

START TRANSACTION;

UPDATE products
SET stock = stock - 1
WHERE id = 5;

-- خطا رخ می‌دهد

ROLLBACK;

در این حالت، کاهش موجودی محصول هم لغو می‌شود.

مثال واقعی: ثبت سفارش بدون Transaction

فرض کنید در یک پروژه فروشگاهی، کد ثبت سفارش به این شکل نوشته شده باشد:

$order = Order::create([
    'user_id' => $user->id,
    'status' => 'pending',
]);

foreach ($cartItems as $item) {
    OrderItem::create([
        'order_id' => $order->id,
        'product_id' => $item['product_id'],
        'quantity' => $item['quantity'],
    ]);

    Product::where('id', $item['product_id'])
        ->decrement('stock', $item['quantity']);
}

Payment::create([
    'order_id' => $order->id,
    'amount' => $totalAmount,
    'status' => 'paid',
]);

در نگاه اول، کد درست به نظر می‌رسد. اما اگر بعد از ایجاد سفارش و چند آیتم، هنگام کاهش موجودی یا ثبت پرداخت خطا رخ دهد، دیتابیس ممکن است در وضعیت ناقص باقی بماند.

نتیجه‌های احتمالی:

• سفارش ثبت شده اما پرداخت ندارد.
• چند آیتم ثبت شده اما موجودی کم نشده است.
• موجودی کم شده اما سفارش کامل نشده است.
• کاربر پیام موفقیت نگرفته اما بخشی از داده ذخیره شده است.

این وضعیت در سیستم‌های واقعی خطرناک است.

استفاده از Transaction در Laravel

Laravel برای مدیریت Transaction، متد DB::transaction را ارائه می‌دهد. طبق مستندات رسمی Laravel، می‌توان مجموعه‌ای از عملیات را داخل Closure متد transaction قرار داد؛ اگر خطایی رخ دهد، تراکنش به‌صورت خودکار Rollback می‌شود و اگر Closure با موفقیت اجرا شود، تراکنش به‌صورت خودکار Commit خواهد شد. مطالعه مستندات رسمی Laravel درباره Database Transactions

نمونه:

use Illuminate\Support\Facades\DB;

DB::transaction(function () {
    DB::update('update users set votes = 1');

    DB::delete('delete from posts');
});

نمونه کاربردی‌تر در Laravel:

use Illuminate\Support\Facades\DB;

$order = DB::transaction(function () use ($user, $cartItems, $totalAmount) {
    $order = Order::create([
        'user_id' => $user->id,
        'status' => 'pending',
        'total_price' => $totalAmount,
    ]);

    foreach ($cartItems as $item) {
        $product = Product::lockForUpdate()
            ->findOrFail($item['product_id']);

        if ($product->stock < $item['quantity']) {
            throw new RuntimeException('موجودی محصول کافی نیست.');
        }

        $order->items()->create([
            'product_id' => $product->id,
            'quantity' => $item['quantity'],
            'unit_price' => $product->price,
        ]);

        $product->decrement('stock', $item['quantity']);
    }

    Payment::create([
        'order_id' => $order->id,
        'amount' => $totalAmount,
        'status' => 'paid',
    ]);

    return $order;
});

در این مثال، اگر هر خطایی رخ دهد، کل عملیات Rollback می‌شود.

مدیریت دستی Transaction در Laravel

در بعضی شرایط، ممکن است بخواهید Transaction را دستی کنترل کنید. Laravel متدهای زیر را در اختیار شما قرار می‌دهد:

DB::beginTransaction();
DB::commit();
DB::rollBack();

نمونه:

use Illuminate\Support\Facades\DB;

try {
    DB::beginTransaction();

    $order = Order::create([
        'user_id' => $user->id,
        'status' => 'pending',
    ]);

    Payment::create([
        'order_id' => $order->id,
        'amount' => 500000,
        'status' => 'paid',
    ]);

    DB::commit();

    return $order;
} catch (Throwable $exception) {
    DB::rollBack();

    throw $exception;
}

روش DB::transaction معمولاً تمیزتر و امن‌تر است، اما روش دستی برای سناریوهای خاص، کنترل بیشتری می‌دهد.

تلاش مجدد در برابر Deadlock در Laravel

در سیستم‌های پرترافیک، گاهی دو Transaction به شکل همزمان منابعی را قفل می‌کنند و منتظر هم می‌مانند. این وضعیت می‌تواند باعث Deadlock شود.

Laravel در متد DB::transaction امکان مشخص کردن تعداد تلاش مجدد را فراهم می‌کند. در مستندات رسمی Laravel آمده است که متد transaction یک آرگومان دوم اختیاری می‌پذیرد که تعداد دفعات تلاش مجدد تراکنش هنگام رخ دادن Deadlock را مشخص می‌کند. مطالعه مستندات رسمی Laravel درباره مدیریت Deadlock در Transaction

نمونه:

DB::transaction(function () {
    // Database operations...
}, 5);

یعنی اگر Deadlock رخ دهد، Laravel تا ۵ بار تلاش می‌کند تراکنش را دوباره اجرا کند.

Lock در Transaction چیست؟

Lock یا قفل‌گذاری یعنی دیتابیس برای جلوگیری از تداخل عملیات‌های همزمان، دسترسی به رکوردها یا منابع خاصی را محدود می‌کند. در Transactionها، Lock نقش مهمی در جلوگیری از Race Condition دارد.

مثلاً وقتی موجودی محصول را بررسی می‌کنید و سپس کاهش می‌دهید، اگر همزمان چند کاربر همان محصول را بخرند، ممکن است خطای فروش بیش از موجودی رخ دهد. برای جلوگیری از این مشکل، می‌توان رکورد محصول را قفل کرد:

$product = Product::where('id', $productId)
    ->lockForUpdate()
    ->firstOrFail();

این دستور باید داخل Transaction استفاده شود:

DB::transaction(function () use ($productId, $quantity) {
    $product = Product::where('id', $productId)
        ->lockForUpdate()
        ->firstOrFail();

    if ($product->stock < $quantity) {
        throw new RuntimeException('موجودی کافی نیست.');
    }

    $product->decrement('stock', $quantity);
});

در این حالت، تراکنش‌های دیگر تا پایان این Transaction نمی‌توانند همان رکورد را برای Update قفل کنند.

Isolation Level چیست؟

Isolation Level سطح جداسازی تراکنش‌ها از یکدیگر را مشخص می‌کند. هرچه Isolation بالاتر باشد، سازگاری بیشتر می‌شود، اما ممکن است کارایی و همزمانی کاهش پیدا کند.

سطوح رایج Isolation عبارت‌اند از:

Dirty Read چیست؟

Dirty Read زمانی رخ می‌دهد که یک Transaction داده‌ای را بخواند که توسط Transaction دیگر تغییر کرده اما هنوز Commit نشده است. اگر تراکنش دوم Rollback شود، تراکنش اول داده‌ای نامعتبر خوانده است.

Non-repeatable Read چیست؟

در یک Transaction، یک رکورد دوبار خوانده می‌شود اما بین دو خواندن، Transaction دیگری آن را تغییر داده و Commit کرده است؛ بنابراین نتیجه دو خواندن متفاوت می‌شود.

Phantom Read چیست؟

در یک Transaction، یک Query چند رکورد را برمی‌گرداند. سپس تراکنش دیگری رکورد جدیدی اضافه می‌کند که با همان شرط مطابقت دارد. اجرای دوباره Query نتیجه متفاوتی می‌دهد.

انتخاب Isolation Level باید بر اساس نیاز پروژه انجام شود. در بسیاری از نرم‌افزارها، سطح پیش‌فرض دیتابیس کافی است؛ اما در سیستم‌های مالی، حسابداری و انبار، ممکن است نیاز به کنترل دقیق‌تر وجود داشته باشد.

Deadlock چیست؟

Deadlock زمانی رخ می‌دهد که دو یا چند Transaction منتظر آزاد شدن منابعی هستند که توسط یکدیگر قفل شده‌اند. مثال ساده:

• Transaction A رکورد محصول ۱ را قفل کرده و منتظر محصول ۲ است.
• Transaction B رکورد محصول ۲ را قفل کرده و منتظر محصول ۱ است.
• هیچ‌کدام نمی‌توانند ادامه دهند.

دیتابیس معمولاً یکی از تراکنش‌ها را متوقف می‌کند تا بن‌بست شکسته شود.

راه‌های کاهش Deadlock

چه چیزهایی نباید داخل Transaction باشد؟

یکی از اشتباهات رایج این است که توسعه‌دهنده هر کاری را داخل Transaction قرار می‌دهد. اما Transaction باید کوتاه، متمرکز و فقط شامل عملیات ضروری دیتابیس باشد.

بهتر است این موارد داخل Transaction قرار نگیرند:

• ارسال ایمیل
• ارسال پیامک
• تماس با API خارجی
• آپلود فایل حجیم
• تولید PDF سنگین
• اجرای پردازش طولانی
• Sleep یا Delay
• درخواست HTTP به سرویس پرداخت
• عملیات زمان‌بر روی Queue

چرا؟ چون Transaction منابع دیتابیس را قفل می‌کند. هرچه بیشتر طول بکشد، احتمال Lock، کندی و Deadlock بیشتر می‌شود.

روش بهتر:

$order = DB::transaction(function () use ($data) {
    return $this->orderService->createOrder($data);
});

SendOrderCreatedNotification::dispatch($order);

در اینجا ابتدا داده‌های حیاتی دیتابیس داخل Transaction ثبت می‌شوند، سپس بعد از موفقیت، Job ارسال اعلان اجرا می‌شود.

Transaction و Queue؛ نکته بسیار مهم

اگر داخل Transaction یک Job Dispatch کنید، ممکن است Job قبل از Commit شدن داده‌ها اجرا شود؛ مخصوصاً اگر Queue سریع پردازش شود. در این حالت، Job ممکن است رکوردی را بخواند که هنوز Commit نشده است.

راه بهتر این است که Job بعد از Commit اجرا شود. در Laravel می‌توان از قابلیت‌های مرتبط با اجرای عملیات بعد از Commit استفاده کرد. این نکته در پروژه‌های واقعی بسیار مهم است، چون ممکن است باعث خطاهای تصادفی و سخت‌دیباگ شود.

نمونه مناسب:

DB::transaction(function () use ($data) {
    $order = Order::create($data);

    SendOrderCreatedNotification::dispatch($order)->afterCommit();
});

یا طراحی را به‌گونه‌ای انجام دهید که Dispatch بعد از خروج موفق از Transaction انجام شود.

Transaction در MySQL و موتور InnoDB

در MySQL، پشتیبانی حرفه‌ای از Transaction معمولاً با موتور ذخیره‌سازی InnoDB انجام می‌شود. اگر جدول شما از موتوری مثل MyISAM استفاده کند، Transaction به شکل مورد انتظار پشتیبانی نمی‌شود.

برای بررسی موتور جدول:

SHOW TABLE STATUS WHERE Name = 'orders';

یا:

SHOW CREATE TABLE orders;

برای ساخت جدول با InnoDB:

CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    total_price BIGINT NOT NULL
) ENGINE=InnoDB;

در پروژه‌های Laravel که از MySQL استفاده می‌کنند، معمولاً جدول‌ها با InnoDB ساخته می‌شوند؛ اما در پروژه‌های قدیمی بهتر است حتماً بررسی شود.

Transaction در PostgreSQL

PostgreSQL نیز از Transactionها به‌صورت قدرتمند پشتیبانی می‌کند. در مستندات رسمی PostgreSQL آمده است که یک Transaction با قرار دادن دستورات SQL بین BEGIN و COMMIT تعریف می‌شود و تغییرات انجام‌شده در یک Transaction باز تا زمان تکمیل، برای سایر Transactionها قابل مشاهده نیستند. مطالعه مستندات رسمی PostgreSQL درباره تراکنش‌ها

نمونه:

BEGIN;

UPDATE accounts
SET balance = balance - 100000
WHERE id = 1;

UPDATE accounts
SET balance = balance + 100000
WHERE id = 2;

COMMIT;

در صورت خطا:

ROLLBACK;

PostgreSQL در پروژه‌هایی که نیاز به سازگاری قوی، Queryهای پیچیده و قابلیت‌های پیشرفته دیتابیس دارند، انتخاب بسیار قدرتمندی است.

طراحی Transaction در Service Layer لاراول

در پروژه‌های حرفه‌ای Laravel، بهتر است Transactionهای مهم داخل Controller نوشته نشوند، بلکه در Service Layer قرار بگیرند.

نمونه Controller:

public function store(StoreOrderRequest $request)
{
    $order = $this->orderService->create(
        $request->validated()
    );

    return redirect()->route('orders.show', $order);
}

نمونه Service:

use Illuminate\Support\Facades\DB;

class OrderService
{
    public function create(array $data): Order
    {
        return DB::transaction(function () use ($data) {
            $order = Order::create([
                'user_id' => $data['user_id'],
                'status' => 'pending',
            ]);

            foreach ($data['items'] as $item) {
                $this->addItemToOrder($order, $item);
            }

            return $order;
        });
    }

    private function addItemToOrder(Order $order, array $item): void
    {
        $product = Product::lockForUpdate()
            ->findOrFail($item['product_id']);

        if ($product->stock < $item['quantity']) {
            throw new RuntimeException('موجودی کافی نیست.');
        }

        $order->items()->create([
            'product_id' => $product->id,
            'quantity' => $item['quantity'],
            'unit_price' => $product->price,
        ]);

        $product->decrement('stock', $item['quantity']);
    }
}

مزیت این طراحی:

• Controller سبک می‌ماند.
• منطق Transaction قابل تست می‌شود.
• کد خواناتر و قابل نگهداری‌تر است.
• فرآیند ثبت سفارش در API، پنل مدیریت یا Command قابل استفاده مجدد می‌شود.

Transaction و Eloquent Model

در Laravel، عملیات Eloquent نیز می‌توانند داخل Transaction قرار بگیرند. برای مثال:

DB::transaction(function () {
    $user = User::create([
        'name' => 'Ali',
        'email' => 'ali@example.com',
    ]);

    $user->profile()->create([
        'bio' => 'Software Developer',
    ]);
});

اگر ایجاد پروفایل خطا بدهد، ایجاد کاربر هم Rollback می‌شود.

نکته مهم این است که همه عملیات داخل Transaction باید از همان Connection دیتابیس استفاده کنند. اگر چند Connection مختلف دارید، باید با دقت بیشتری طراحی کنید؛ چون Transaction معمولی روی یک Connection اعمال می‌شود.

Nested Transaction در Laravel

گاهی ممکن است یک Transaction داخل Transaction دیگر فراخوانی شود. Laravel تا حدی این وضعیت را مدیریت می‌کند، اما باید با احتیاط طراحی شود. مشکل اصلی این است که اگر Serviceهای مختلف هرکدام Transaction مستقل باز کنند، رفتار کلی سیستم ممکن است پیچیده و سخت‌دیباگ شود.

بهتر است برای عملیات‌های بزرگ، یک Service سطح بالاتر مسئول Transaction اصلی باشد و متدهای داخلی فقط عملیات لازم را انجام دهند.

نمونه بهتر:

class CheckoutService
{
    public function checkout(array $data): Order
    {
        return DB::transaction(function () use ($data) {
            $order = $this->orderService->createWithoutTransaction($data);

            $this->paymentService->createPendingPayment($order);

            return $order;
        });
    }
}

این ساختار باعث می‌شود مرز Transaction واضح‌تر باشد.

Transaction و تست‌نویسی

در تست‌های Laravel، معمولاً از Traitهایی مثل RefreshDatabase استفاده می‌شود. همچنین در بعضی پروژه‌ها برای سرعت بیشتر، تست‌ها داخل Transaction اجرا می‌شوند و بعد از پایان تست Rollback می‌شوند.

اما وقتی خود کد برنامه Transaction دارد، باید تست‌ها با دقت نوشته شوند تا رفتار واقعی سیستم بررسی شود.

نمونه تست ثبت سفارش:

public function test_order_creation_rolls_back_when_stock_is_not_enough(): void
{
    $product = Product::factory()->create([
        'stock' => 1,
    ]);

    $this->expectException(RuntimeException::class);

    app(OrderService::class)->create([
        'user_id' => User::factory()->create()->id,
        'items' => [
            [
                'product_id' => $product->id,
                'quantity' => 2,
            ],
        ],
    ]);

    $this->assertDatabaseMissing('order_items', [
        'product_id' => $product->id,
    ]);
}

هدف تست این است که مطمئن شویم در صورت خطا، داده ناقص در دیتابیس باقی نمی‌ماند.

خطاهای رایج در استفاده از Transaction

1. فراموش کردن Transaction در عملیات چندمرحله‌ای

اگر عملیات شما چند جدول را تغییر می‌دهد، احتمالاً به Transaction نیاز دارید.

2. قرار دادن عملیات خارجی داخل Transaction

ارسال پیامک، ایمیل یا درخواست HTTP داخل Transaction می‌تواند باعث طولانی شدن قفل‌ها و افزایش Deadlock شود.

3. گرفتن Lock بدون نیاز

Lock اضافی می‌تواند کارایی سیستم را پایین بیاورد. فقط زمانی از lockForUpdate استفاده کنید که واقعاً نیاز دارید.

4. نبود Index مناسب

Queryهای داخل Transaction اگر Index نداشته باشند، ممکن است ردیف‌های زیادی را قفل کنند و باعث کندی شوند.

5. Transactionهای بسیار طولانی

Transaction باید کوتاه باشد. Transaction طولانی یعنی قفل طولانی و احتمال بیشتر برای مشکل در همزمانی.

6. مدیریت نکردن Exception

اگر Exception درست مدیریت نشود، ممکن است Rollback یا پیام خطا به شکل مناسب انجام نشود.

7. تکیه کامل بر Transaction برای قوانین تجاری

Transaction مهم است، اما جایگزین Validation، Constraint دیتابیس، Unique Index، Foreign Key و منطق دامنه نیست.

بهترین روش‌های استفاده از Transaction دیتابیس

1. فقط عملیات ضروری دیتابیس را داخل Transaction بگذارید

Transaction را کوتاه و متمرکز نگه دارید.

2. از DB::transaction در Laravel استفاده کنید

برای بیشتر سناریوها، این روش تمیزتر و امن‌تر از مدیریت دستی است.

3. برای عملیات حساس از Lock مناسب استفاده کنید

در سناریوهایی مانند موجودی کالا، رزرو ظرفیت یا انتقال وجه، lockForUpdate می‌تواند ضروری باشد.

4. خطاها را شفاف مدیریت کنید

Exceptionهای اختصاصی مثل InsufficientStockException یا PaymentFailedException خوانایی و کنترل خطا را بهتر می‌کنند.

5. عملیات خارجی را بعد از Commit انجام دهید

ارسال ایمیل، پیامک و Jobهای غیرحیاتی بهتر است بعد از موفقیت Transaction انجام شوند.

6. ترتیب قفل‌گذاری را ثابت نگه دارید

برای کاهش Deadlock، منابع را همیشه با ترتیب مشخص قفل کنید؛ مثلاً همیشه بر اساس id صعودی.

7. از Index مناسب استفاده کنید

Queryهای داخل Transaction باید سریع و دقیق باشند.

8. تراکنش‌ها را در Service Layer طراحی کنید

برای پروژه‌های حرفه‌ای، Service Layer محل مناسبی برای مدیریت Transactionهای تجاری است.

9. سناریوهای شکست را تست کنید

فقط تست موفقیت کافی نیست. باید تست کنید اگر وسط عملیات خطا رخ دهد، داده ناقص باقی نماند.

10. Isolation Level را بدون نیاز تغییر ندهید

سطح پیش‌فرض دیتابیس معمولاً مناسب است. تغییر Isolation Level باید با شناخت دقیق انجام شود.

جدول مقایسه مفاهیم کلیدی Transaction

نمونه کامل: Transaction برای ثبت سفارش در Laravel

در این بخش یک نمونه نسبتاً کامل برای ثبت سفارش در Laravel می‌بینیم.

OrderService

<?php

namespace App\Services;

use App\Exceptions\InsufficientStockException;
use App\Models\Order;
use App\Models\Product;
use Illuminate\Support\Facades\DB;

class OrderService
{
    public function create(array $data): Order
    {
        return DB::transaction(function () use ($data) {
            $order = Order::create([
                'user_id' => $data['user_id'],
                'status' => 'pending',
                'total_price' => 0,
            ]);

            $totalPrice = 0;

            foreach ($data['items'] as $item) {
                $product = Product::query()
                    ->where('id', $item['product_id'])
                    ->lockForUpdate()
                    ->firstOrFail();

                if ($product->stock < $item['quantity']) {
                    throw new InsufficientStockException(
                        'موجودی محصول کافی نیست.'
                    );
                }

                $lineTotal = $product->price * $item['quantity'];

                $order->items()->create([
                    'product_id' => $product->id,
                    'quantity' => $item['quantity'],
                    'unit_price' => $product->price,
                    'total_price' => $lineTotal,
                ]);

                $product->decrement('stock', $item['quantity']);

                $totalPrice += $lineTotal;
            }

            $order->update([
                'total_price' => $totalPrice,
                'status' => 'created',
            ]);

            return $order;
        }, 3);
    }
}

Controller

<?php

namespace App\Http\Controllers;

use App\Http\Requests\StoreOrderRequest;
use App\Services\OrderService;

class OrderController extends Controller
{
    public function __construct(
        protected OrderService $orderService
    ) {}

    public function store(StoreOrderRequest $request)
    {
        $order = $this->orderService->create(
            $request->validated()
        );

        return redirect()
            ->route('orders.show', $order)
            ->with('success', 'سفارش با موفقیت ثبت شد.');
    }
}

در این طراحی:

• کنترلر سبک است.
• منطق تجاری در Service قرار دارد.
• سفارش و آیتم‌ها داخل Transaction ساخته می‌شوند.
• موجودی محصول با Lock کنترل می‌شود.
• در صورت خطا، کل عملیات Rollback می‌شود.
• تعداد تلاش مجدد برای Deadlock مشخص شده است.

Transaction و عملکرد سیستم

Transactionها برای حفظ سازگاری داده ضروری هستند، اما استفاده نادرست از آن‌ها می‌تواند Performance را کاهش دهد. هر Transaction ممکن است Lock ایجاد کند و منابع دیتابیس را درگیر نگه دارد. بنابراین باید تعادل بین صحت داده و عملکرد سیستم حفظ شود.

نکات عملکردی مهم

• Queryهای داخل Transaction باید تا حد امکان سریع باشند.
• ستون‌هایی که در شرط‌های WHERE استفاده می‌شوند باید Index مناسب داشته باشند.
• از خواندن حجم زیادی از داده داخل Transaction پرهیز کنید.
• عملیات محاسباتی سنگین را قبل یا بعد از Transaction انجام دهید.
• Transaction را زود شروع و دیر تمام نکنید.
• فقط بخش حیاتی عملیات را داخل Transaction قرار دهید.

مثال نامناسب:

DB::transaction(function () {
    $report = $this->generateLargeReport();

    $response = Http::post('https://external-api.test', [
        'report' => $report,
    ]);

    Report::create([
        'status' => 'sent',
    ]);
});

مثال بهتر:

$report = $this->generateLargeReport();

DB::transaction(function () use ($report) {
    Report::create([
        'status' => 'created',
        'summary' => $report->summary,
    ]);
});

SendReportToExternalApi::dispatch($report);

Transaction در معماری نرم‌افزار

Transaction فقط یک ابزار دیتابیس نیست؛ بلکه باید بخشی از طراحی معماری نرم‌افزار باشد. در پروژه‌های حرفه‌ای، باید از ابتدا مشخص شود:

• کدام عملیات‌ها نیازمند Atomicity هستند؟
• مرز Transaction کجاست؟
• چه داده‌هایی باید Lock شوند؟
• اگر عملیات خارجی شکست بخورد، وضعیت دیتابیس چه می‌شود؟
• اگر پرداخت موفق باشد اما ثبت سفارش شکست بخورد، چه سناریویی اجرا می‌شود؟
• آیا عملیات باید جبران‌پذیر باشد؟
• آیا نیاز به Outbox Pattern یا Saga وجود دارد؟

در سیستم‌های ساده، Transaction دیتابیس کافی است. اما در سیستم‌های توزیع‌شده، Microserviceها یا چند دیتابیس، Transaction سنتی همیشه کافی نیست و باید سراغ الگوهایی مانند Saga، Outbox Pattern یا Eventual Consistency رفت. البته برای بیشتر پروژه‌های Laravel تک‌دیتابیسی، Transaction دیتابیس همچنان بهترین و ساده‌ترین راه حفظ سازگاری داده است.

Transaction و امنیت داده

Transaction به‌طور مستقیم ابزار امنیتی مثل احراز هویت یا رمزنگاری نیست، اما در امنیت عملیاتی داده نقش مهمی دارد. وقتی داده مالی یا سازمانی ناقص ثبت شود، ممکن است مسیر سوءاستفاده، خطای مالی یا دستکاری ناخواسته باز شود.

برای مثال:

• اگر پرداخت ثبت شود اما سفارش ایجاد نشود، اختلاف مالی ایجاد می‌شود.
• اگر سطح دسترسی کاربر تغییر کند اما لاگ ثبت نشود، ردیابی امنیتی سخت می‌شود.
• اگر انتقال مالکیت رکورد ناقص بماند، داده ممکن است در اختیار فرد اشتباه قرار گیرد.
• اگر موجودی کالا اشتباه شود، سیستم ممکن است فروش غیرواقعی انجام دهد.

بنابراین Transaction بخشی از طراحی قابل اعتماد و امن سیستم است.

FAQ؛ سوالات متداول درباره Transaction دیتابیس

1. Transaction دیتابیس چیست؟

Transaction مجموعه‌ای از عملیات دیتابیس است که به‌صورت یک واحد اجرا می‌شود. اگر همه عملیات‌ها موفق باشند، تغییرات Commit می‌شوند و اگر خطایی رخ دهد، همه تغییرات Rollback می‌شوند.

2. چرا Transaction مهم است؟

چون از ناقص ماندن عملیات‌های چندمرحله‌ای جلوگیری می‌کند. در سیستم‌های مالی، فروشگاهی، حسابداری و سازمانی، Transaction برای حفظ سازگاری داده ضروری است.

3. Commit یعنی چه؟

Commit یعنی تغییرات انجام‌شده در یک Transaction تأیید و دائمی شوند.

4. Rollback یعنی چه؟

Rollback یعنی تغییرات انجام‌شده در یک Transaction لغو شوند و دیتابیس به وضعیت قبل از شروع تراکنش برگردد.

5. ACID چیست؟

ACID چهار اصل مهم برای تراکنش‌های قابل اعتماد است: Atomicity، Consistency، Isolation و Durability.

6. در Laravel چطور Transaction بنویسیم؟

در Laravel معمولاً از DB::transaction استفاده می‌شود:

DB::transaction(function () {
    // database operations
});

اگر خطایی رخ دهد، Laravel به‌صورت خودکار Rollback می‌کند و اگر عملیات موفق باشد، Commit انجام می‌دهد.

7. Deadlock چیست؟

Deadlock زمانی رخ می‌دهد که دو یا چند Transaction منتظر آزاد شدن منابعی باشند که توسط یکدیگر قفل شده‌اند. دیتابیس معمولاً یکی از تراکنش‌ها را متوقف می‌کند.

8. lockForUpdate در Laravel چه کاربردی دارد؟

lockForUpdate برای قفل کردن رکورد جهت به‌روزرسانی استفاده می‌شود. این قابلیت در سناریوهایی مثل کنترل موجودی کالا، رزرو ظرفیت و عملیات مالی کاربرد دارد و باید داخل Transaction استفاده شود.

9. آیا باید ارسال ایمیل را داخل Transaction انجام دهیم؟

معمولاً خیر. ارسال ایمیل، پیامک یا درخواست به API خارجی بهتر است بعد از Commit انجام شود، چون این عملیات‌ها زمان‌بر هستند و ممکن است باعث طولانی شدن Transaction شوند.

10. آیا همه عملیات‌ها نیاز به Transaction دارند؟

خیر. اگر فقط یک عملیات ساده و مستقل انجام می‌دهید، ممکن است نیازی به Transaction نداشته باشید. اما اگر چند عملیات وابسته به هم دارید، استفاده از Transaction بسیار مهم است.

11. آیا Transaction باعث کندی سیستم می‌شود؟

اگر درست استفاده شود، ضروری و قابل قبول است. اما Transactionهای طولانی، Queryهای بدون Index و Lockهای غیرضروری می‌توانند باعث کندی و Deadlock شوند.

12. آیا Transaction جایگزین Validation است؟

خیر. Transaction فقط اجرای اتمی عملیات را مدیریت می‌کند. همچنان باید از Validation، Constraint، Foreign Key، Unique Index و منطق تجاری درست استفاده شود.

جمع‌بندی

Transaction دیتابیس یکی از پایه‌های اصلی ساخت نرم‌افزارهای قابل اعتماد است. هرجا چند عملیات دیتابیس به هم وابسته هستند، باید به این فکر کنیم که اگر یکی از مراحل شکست بخورد، وضعیت داده‌ها چه خواهد شد. Transaction کمک می‌کند عملیات‌های مرتبط به‌صورت یک واحد کامل اجرا شوند؛ یعنی یا همه موفق شوند یا همه به حالت قبل برگردند.

مفاهیمی مانند ACID، Commit، Rollback، Isolation Level، Lock و Deadlock برای درک درست Transaction ضروری هستند. در Laravel، متد DB::transaction راهکاری ساده و قدرتمند برای مدیریت تراکنش‌ها فراهم می‌کند و در کنار قابلیت‌هایی مثل lockForUpdate، Service Layer، Exception Handling و Queue می‌توان فرآیندهای پیچیده‌ای مثل ثبت سفارش، پرداخت، انتقال وجه، مدیریت موجودی و صدور فاکتور را با اطمینان بیشتری پیاده‌سازی کرد.

نکته مهم این است که Transaction باید درست و هدفمند استفاده شود. Transaction طولانی، عملیات خارجی داخل تراکنش، نبود Index مناسب، Lockهای غیرضروری و مدیریت نادرست Exception می‌توانند باعث کندی، Deadlock و خطاهای پیچیده شوند. در پروژه‌های حرفه‌ای، بهترین کار این است که مرز Transactionها در Service Layer مشخص شود، عملیات دیتابیس کوتاه و متمرکز بماند و عملیات جانبی مثل ایمیل و پیامک بعد از Commit اجرا شوند.

برای شرکت‌های تولید نرم‌افزار، تسلط بر Transaction فقط یک مهارت دیتابیسی نیست؛ بلکه یک اصل مهم در طراحی محصولاتی است که باید قابل اعتماد، دقیق، مقیاس‌پذیر و آماده استفاده در محیط واقعی باشند. 💼

CTA

اگر پروژه نرم‌افزاری شما با عملیات حساس مانند پرداخت، سفارش، حسابداری، مدیریت انبار، رزرو، اشتراک یا داده‌های سازمانی سروکار دارد، طراحی درست Transactionها می‌تواند از بسیاری از خطاهای پرهزینه جلوگیری کند. تیم ما می‌تواند در طراحی معماری دیتابیس، پیاده‌سازی Transactionهای امن در Laravel، بهینه‌سازی Queryها، کاهش Deadlock، بازطراحی Service Layer و افزایش پایداری نرم‌افزار به شما کمک کند. برای بررسی فنی پروژه خود با ما تماس بگیرید و زیرساخت داده‌ای محصولتان را حرفه‌ای‌تر و قابل اعتمادتر بسازید. 🚀

منابع رسمی

1. مستندات رسمی Laravel درباره Database Transactions؛ برای یادگیری استفاده از DB::transaction، مدیریت دستی Transaction و تلاش مجدد هنگام Deadlock.
   مطالعه مستندات رسمی Laravel درباره Database Transactions
2. مستندات رسمی MySQL درباره InnoDB و مدل ACID؛ برای آشنایی با اصول ACID و نقش InnoDB در تراکنش‌های قابل اعتماد.
   مطالعه مستندات رسمی MySQL درباره InnoDB و ACID
3. معرفی رسمی InnoDB در مستندات Oracle MySQL؛ برای بررسی پشتیبانی InnoDB از Commit، Rollback و Crash Recovery.
   مطالعه معرفی رسمی InnoDB در MySQL
4. مستندات رسمی PostgreSQL درباره Transactions؛ برای درک مفهوم BEGIN، COMMIT، ROLLBACK و رفتار تراکنش‌ها در PostgreSQL.
   مطالعه مستندات رسمی PostgreSQL درباره Transactions