ನೀವು ಆರ್ಡರ್ ಅನ್ನು ಉಳಿಸಿದಿರಿ, ಆದರೆ ಆರ್ಡರ್ ಐಟಂಗಳು ಡೇಟಾಬೇಸ್ಗೆ ತಲುಪಲಿಲ್ಲ. ಅಥವಾ ಸ್ಟಾಕ್ ಕೌಂಟರ್ ಕಡಿಮೆಯಾಗಬಹುದು, ಪೇಮೆಂಟ್ ಗೇಟ್ವೇ ಟೈಮೌಟ್ ಆಗಬಹುದು, ಮತ್ತು ಈಗ ಗ್ರಾಹಕರ ಕಾರ್ಡ್ನಿಂದ ಹಣ ಕಡಿತವಾಗಿದೆ ಆದರೆ ಆರ್ಡರ್ ದಾಖಲೆ ಇಲ್ಲದಿರಬಹುದು. ಇಂತಹ ಸಂದರ್ಭಗಳು ಸಾಮಾನ್ಯವಲ್ಲ ಎಂದು ಅನಿಸಬಹುದು, ಆದರೆ ಅವುಗಳು ಅನಿವಾರ್ಯವಾದಾಗ ಅವು ದೈನಂದಿನ ತಲೆನೋವುಗಳಾಗುತ್ತವೆ.
ಇದರ ಮೂಲ ಕಾರಣ ಯಾವಾಗಲೂ ಒಂದೇ ಆಗಿರುತ್ತದೆ: ಪ್ರತ್ಯೇಕ, ಪ್ರತ್ಯೇಕ ಘಟನೆಗಳೆಂದು ಪರಿಗಣಿಸಲ್ಪಟ್ಟ ಡೇಟಾಬೇಸ್ ಬರವಣಿಗೆಗಳ ಸರಣಿ. ಒಂದು ವಿಫಲವಾದರೆ, ಉಳಿದವುಗಳು ಹಿಂದೆಯೇ ಉಳಿದುಬಿಡುತ್ತವೆ. ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ ಡೇಟಾಬೇಸ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್ (database transaction), ಮತ್ತು Laravel ನಲ್ಲಿ, ಅದಕ್ಕಾಗಿ ಇರುವ ಸಾಧನವೇ DB::transaction().
ಟ್ರಾನ್ಸಾಕ್ಷನ್ ವಾಸ್ತವವಾಗಿ ಏನು ಭರವಸೆ ನೀಡುತ್ತದೆ
ಡೇಟಾಬೇಸ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಹಲವಾರು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು (operations) ಒಂದೇ ಕೆಲಸದ ಘಟಕವಾಗಿ (single unit of work) ಬಂಧಿಸುತ್ತದೆ. ಒಳಗಿರುವ ಎಲ್ಲವೂ ಶಾಶ್ವತವಾಗಿ ಕಮಿಟ್ (commit) ಆಗಬೇಕು ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ರೋಲ್ ಬ್ಯಾಕ್ (roll back) ಆಗಬೇಕು ಎಂದು ಡೇಟಾಬೇಸ್ ಎಂಜಿನ್ ಖಾತರಿ ನೀಡುತ್ತದೆ. ಇಲ್ಲಿ ಮಧ್ಯಮ ಮಾರ್ಗವಿಲ್ಲ.
ಬ್ಯಾಂಕ್ ವರ್ಗಾವಣೆಯನ್ನು (bank transfer) ನೆನಪಿಸಿಕೊಳ್ಳಿ. ಸಿಸ್ಟಮ್ ಒಂದು ಖಾತೆಯಿಂದ ಹಣವನ್ನು ಕಡಿತಗೊಳಿಸಿ (debit) ಮತ್ತೊಂದು ಖಾತೆಗೆ ಜಮಾ (credit) ಮಾಡಬೇಕು. ಕಡಿತಗೊಳಿಸಿದ ನಂತರ ಜಮಾ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆ ವಿಫಲವಾದರೆ, ಹಣವು ಸುಮ್ಮನೆ ಮಾಯವಾಗುವುದಿಲ್ಲ. ಬ್ಯಾಂಕ್ ಆ ಕಡಿತವನ್ನು ಹಿಂಪಡೆಯುತ್ತದೆ (reverse). ಆ ಹಿಂಪಡೆಯುವಿಕೆಯೇ ರೋಲ್ ಬ್ಯಾಕ್ (rollback). ಎರಡೂ ಹಂತಗಳು ಯಶಸ್ವಿಯಾದರೆ, ವರ್ಗಾವಣೆಯು ಕಮಿಟ್ (commit) ಆಗುತ್ತದೆ, ಅಂದರೆ ಹೊಸ ಬ್ಯಾಲೆನ್ಸ್ ಶಾಶ್ವತವಾಗಿ ಉಳಿಸಲ್ಪಡುತ್ತದೆ.
ಈ 'ಎಲ್ಲವೂ ಅಥವಾ ಯಾವುದೂ ಇಲ್ಲ' (all-or-nothing) ಎಂಬ ವರ್ತನೆಯೇ ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಸ್ಥಿರವಾಗಿ (consistent) ಇಡುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಭಾಗಶಃ ವಿಫಲತೆಗಳು ನಿಮ್ಮ ಟೇಬಲ್ಗಳಲ್ಲಿ ಅರ್ಧಬರೆದ ದಾಖಲೆಗಳನ್ನು ಹರಡುತ್ತವೆ, ಮತ್ತು ಯಾವುದೇ ಸ್ವಯಂಚಾಲಿತ ಪ್ರಕ್ರಿಯೆಗೆ ಅವುಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಹೇಗೆ ಸ್ವಚ್ಛಗೊಳಿಸಬೇಕೆಂದು ತಿಳಿಯದ ಕಾರಣ ಆ ದಾಖಲೆಗಳು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ವ್ಯರ್ಥವಾಗಿ ಉಳಿಯುತ್ತವೆ.
Laravel ಇದನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ
ಸಾಮಾನ್ಯ SQL ನಲ್ಲಿ, ನೀವು BEGIN, COMMIT, ಮತ್ತು ROLLBACK ಅನ್ನು ನೀವೇ ಬರೆಯಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಅರ್ಧಕ್ಕೆ ನಿಲ್ಲದಂತೆ ನೋಡಿಕೊಳ್ಳಲು ಪ್ರತಿಯೊಂದು ಸಂಭವನೀಯ ದೋಷವನ್ನು (error) ಹಿಡಿಯುವುದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕು. Laravel ಆ ಎಲ್ಲಾ ಸಂಕೀರ್ಣ ಕೆಲಸಗಳನ್ನು ಒಂದು ಸಿಂಗಲ್ ಮೆಥಡ್ನಲ್ಲಿ ಅಡಗಿಸಿಡುತ್ತದೆ.
ನೀವು DB::transaction() ಗೆ ಒಂದು closure ಅನ್ನು ನೀಡುತ್ತೀರಿ. Laravel ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಒಂದು ವೇಳೆ closure ಯಾವುದೇ exception ಎಸೆಯದೆ ಮುಕ್ತಾಯಗೊಂಡರೆ, ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಮಿಟ್ ಆಗುತ್ತದೆ. ಏನಾದರೂ ವಿಫಲವಾದರೆ, Laravel ಆ exception ಅನ್ನು ಹಿಡಿದು, ಎಲ್ಲವನ್ನೂ ರೋಲ್ ಬ್ಯಾಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಲಾಗಿಂಗ್ ಮತ್ತು ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ನಿರೀಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲಿ ಎನ್ನುವಂತೆ ದೋಷವನ್ನು ಮತ್ತೆ ಎಸೆಯುತ್ತದೆ (rethrow).
use Illuminate\Support\Facades\DB;
DB::transaction(function () {
$order = Order::create([/* ... */]);
foreach ($cart->items as $item) {
OrderItem::create([
'order_id' => $order->id,
'product_id' => $item->product_id,
'quantity' => $item->quantity,
]);
Product::find($item->product_id)
->decrement('stock', $item->quantity);
}
Payment::create([
'order_id' => $order->id,
'amount' => $cart->total,
'status' => 'completed',
]);
});
ಫಾರಿನ್ ಕೀ (foreign key) ಇಲ್ಲದ ಕಾರಣ ಅಥವಾ ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ ಕಡಿತಗೊಂಡ ಕಾರಣ ಪೇಮೆಂಟ್ ಇನ್ಸರ್ಟ್ ವಿಫಲವಾದರೆ, ಆರ್ಡರ್, ಆರ್ಡರ್ ಐಟಂಗಳು ಮತ್ತು ಸ್ಟಾಕ್ ಬದಲಾವಣೆಗಳೆಲ್ಲವೂ ರದ್ದಾಗುತ್ತವೆ. ಯಾವುದೇ ಕಾರಣವಿಲ್ಲದೆ ಸ್ಟಾಕ್ ಮಾಯವಾಗುವ ಅಥವಾ ಪಾವತಿಸದ ಆರ್ಡರ್ ಅನ್ನು ಶಿಪ್ಪಿಂಗ್ ಮಾಡಲು ಕೇಳುವಂತಹ ಪರಿಸ್ಥಿತಿ ನಿಮಗೆ ಎದುರಾಗುವುದಿಲ್ಲ.
ಇದು ನಿಮಗೆ ಎಲ್ಲಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ
ಕೆಲವು ವರ್ಕ್ಫ್ಲೋಗಳು (workflows) ಸಂಪೂರ್ಣವಾಗಿ ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಸುರಕ್ಷತೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿವೆ. ಚೆಕ್ಔಟ್ ಉದಾಹರಣೆಯು ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾಗಿದೆ, ಆದರೆ ಈ ಮಾದರಿಯು ಎಲ್ಲೆಡೆ ಕಂಡುಬರುತ್ತದೆ.
ಬಳಕೆದಾರರ ನೋಂದಣಿ (User registration). ಬಳಕೆದಾರರ ಸಾಲನ್ನು (user row) ರಚಿಸುವುದು, ನಂತರ ಪ್ರೊಫೈಲ್ ಸಾಲನ್ನು ರಚಿಸುವುದು, ನಂತರ ಡಿಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಮಾಡುವುದು. ವ್ಯಾಲಿಡೇಶನ್ ಸಮಸ್ಯೆಯಿಂದಾಗಿ ಪ್ರೊಫೈಲ್ ಇನ್ಸರ್ಟ್ ವಿಫಲವಾದರೆ, ಪ್ರೊಫೈಲ್ ಇಲ್ಲದ ಬಳಕೆದಾರರು 'ಘೋಸ್ಟ್ ಅಕೌಂಟ್' (ghost account) ಆಗುತ್ತಾರೆ. ಪ್ರತಿಯೊಬ್ಬ ಬಳಕೆದಾರನಿಗೂ ಪ್ರೊಫೈಲ್ ಇದೆ ಎಂದು ಭಾವಿಸುವ ಯಾವುದೇ ಪೇಜ್ ಕ್ರ್ಯಾಶ್ ಆಗಬಹುದು ಅಥವಾ ಮುರಿದ UI ಅನ್ನು ತೋರಿಸಬಹುದು.
ಬಲ್ಕ್ ಇಂಪೋರ್ಟ್ಸ್ (Bulk imports). ಐವತ್ತು ದಾಖಲೆಗಳನ್ನು ಇನ್ಸರ್ಟ್ ಮಾಡುವ CSV ಅಪ್ಲೋಡ್ನಲ್ಲಿ, ಇಪ್ಪತ್ತೈದನೇ ಸಾಲಿನಲ್ಲಿ ತಪ್ಪು ದಿನಾಂಕವಿದ್ದ ಕಾರಣ ಇಪ್ಪತ್ತೈದು ದಾಖಲೆಗಳು ಉಳಿದುಹೋಗಬಾರದು. ಇಡೀ ಬ್ಯಾಚ್ ಅನ್ನು ಒಂದು ಟ್ರಾನ್ಸಾಕ್ಷನ್ನಲ್ಲಿ ಸುತ್ತುವರಿಯುವುದು (wrapping) ಇಡೀ ಇಂಪೋರ್ಟ್ ಅನ್ನು ಒಂದೇ ಘಟಕವಾಗಿ ವಿಫಲವಾಗಲು ಅನುಮತಿಸುತ್ತದೆ. ಅಡ್ಮಿನ್ ಯಾವ ಸಾಲುಗಳು ಭಾಗಶಃ ಸೋರಿಕೆಯಾಗಿವೆ ಎಂದು ಹುಡುಕಲು ಗಂಟೆಗಟ್ಟಲೆ ಸಮಯ ವ್ಯಯಿಸುವ ಬದಲು, ಫೈಲ್ ಅನ್ನು ಸರಿಪಡಿಸಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದು.
ಇನ್ವೆಂಟರಿ ಮತ್ತು ಅಕೌಂಟಿಂಗ್ (Inventory and accounting). ಒಂದು ಟೇಬಲ್ ಭೌತಿಕ ಸಂಪನ್ಮೂಲವನ್ನು (physical resource) ಟ್ರ್ಯಾಕ್ ಮಾಡುವಾಗ ಮತ್ತು ಇನ್ನೊಂದು ಟೇಬಲ್ ಹಣ ಅಥವಾ ಕ್ರೆಡಿಟ್ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವಾಗ, ಇವೆರಡೂ ಒಟ್ಟಿಗೆ ಚಲಿಸಬೇಕು. ಇವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಹೊಂದಾಣಿಕೆಯಾಗದ ಆಡಿಟ್ಗಳು ಮತ್ತು ಸುಳ್ಳು ವರದಿಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಯಾವಾಗ ನೀವು ಮ್ಯಾನುಯಲ್ ಆಗಿ ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ
Closure ವಿಧಾನವು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ನಿಮಗೆ ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣದ ಅಗತ್ಯವಿರುತ್ತದೆ. ಸರ್ವಿಸ್ ಕ್ಲಾಸ್ನಲ್ಲಿ ಸಂಕೀರ್ಣವಾದ ಕಂಡೀಷನಲ್ ಲಾಜಿಕ್ ಇರುವುದು ಅಥವಾ ರನ್-ಟೈಮ್ನಲ್ಲಿ ಕಮಿಟ್ ಮಾಡಬೇಕೆ ಅಥವಾ ಬೇಡವೇ ಎಂದು ನಿರ್ಧರಿಸಬೇಕಾದ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಿಂಗಲ್ closure ಅಸಮರ್ಪಕವಾಗಿ ಕಾಣಿಸಬಹುದು. ಅಂತಹ ಕ್ಷಣಗಳಲ್ಲಿ, ನೀವು ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಅನ್ನು ನೀವೇ ನಿರ್ವಹಿಸಬಹುದು:
DB::beginTransaction();
try {
// Run your operations
$order = Order::create([/* ... */]);
// ... more work ...
if ($someBusinessRulePasses) {
DB::commit();
} else {
DB::rollBack();
}
} catch (\Throwable $e) {
DB::rollBack();
throw $e;
}
catch ಬ್ಲಾಕ್ ಒಳಗಿನ ಕ್ರಮವನ್ನು ಗಮನಿಸಿ: ಮೊದಲು ರೋಲ್ ಬ್ಯಾಕ್ ಮಾಡಿ, ನಂತರ ಎಸೆಯಿರಿ (throw). ನೀವು ರೋಲ್ ಬ್ಯಾಕ್ ಮಾಡುವ ಮೊದಲು ಎಸೆಯುವಲ್ಲಿ, ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಕನೆಕ್ಷನ್ನಲ್ಲಿ ತೆರೆದೆಯೇ ಇರುತ್ತದೆ. ಇದು ರೋಗಳನ್ನು ಲಾಕ್ ಮಾಡಬಹುದು, ಇತರ ಕ್ವೇರಿಗಳಿಗೆ ಡೆಡ್ಲಾಕ್ (deadlock) ಉಂಟುಮಾಡಬಹುದು ಅಥವಾ ನಿಮ್ಮ ಕನೆಕ್ಷನ್ ಪೂಲ್ ಅನ್ನು ಖಾಲಿ ಮಾಡಬಹುದು. ಮ್ಯಾನುಯಲ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್ಗಳು ಶಕ್ತಿಯುತವಾಗಿವೆ, ಆದರೆ ಅವು ಕ್ಲೀನಪ್ ಮಾಡುವ ಹೊಣೆಗಾರಿಕೆಯನ್ನು ನಿಮ್ಮ ಮೇಲಿಡುತ್ತವೆ.
ಸೈಡ್ ಎಫೆಕ್ಟ್ಗಳನ್ನು (Side Effects) ಟ್ರಾನ್ಸಾಕ್ಷನ್ನಿಂದ ಹೊರಗಿಡಿ
ಇದು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ತಂಡಗಳಿಗೆ ತೊಂದರೆ ನೀಡುವ ನಿಯಮವಾಗಿದೆ. ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಡೇಟಾಬೇಸ್ ಕೆಲಸವನ್ನು ಮಾತ್ರ ಹಿಂಪಡೆಯಬಲ್ಲದು. ಇದು ಕಳುಹಿಸಿದ ಇಮೇಲ್ ಅನ್ನು ಹಿಂಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ, ಕ್ಲೌಡ್ ಸ್ಟೋರೇಜ್ನಿಂದ ಫೈಲ್ ಅನ್ನು ಡಿಲೀಟ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಅಥವಾ ಪೇಮೆಂಟ್ API ಮೂಲಕ ಹಣವನ್ನು ಮರುಪಾವತಿಸಲು (refund) ಸಾಧ್ಯವಿಲ್ಲ.
ನೀವು ಟ್ರಾನ್ಸಾಕ್ಷನ್ closure ಒಳಗೆ Mail::send() ಕಾಲ್ ಅನ್ನು ಇಟ್ಟರೆ ಮತ್ತು ಎರಡು ಸಾಲುಗಳ ನಂತರ ಡೇಟಾಬೇಸ್ ರೋಲ್ ಬ್ಯಾಕ್ ಆದರೆ, ಆ ಇಮೇಲ್ ಗ್ರಾಹಕರ ಇನ್ಬಾಕ್ಸ್ಗೆ ತಲುಪುತ್ತದೆ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಆರ್ಡರ್ಗಾಗಿ ಸ್ವೀಕರಿಸುವವರಿಗೆ ಇನ್ವಾಯ್ಸ್ ಸಿಗುತ್ತದೆ. Slack ನೋಟಿಫಿಕೇಶನ್ಗಳು, S3 ಗೆ ಫೈಲ್ ಅಪ್ಲೋಡ್ಗಳು ಅಥವಾ ವೆಬ್ಹುಕ್ ಡಿಸ್ಪ್ಯಾಚ್ಗಳಿಗೂ ಇದು ಅನ್ವಯಿಸುತ್ತದೆ.
ಸರಿಯಾದ ಕ್ರಮ ಹೀಗಿದೆ:
- ವಹಿವಾಟನ್ನು (transaction) ಪೂರ್ಣಗೊಳಿಸಿ ಮತ್ತು ನಿಮಗೆ ಬೇಕಾದ ಯಾವುದೇ ID ಅಥವಾ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆದುಕೊಳ್ಳಿ.
- ಅದರ ನಂತರವಷ್ಟೇ ಬಾಹ್ಯ ಪರಿಣಾಮಗಳನ್ನು (external side effects) ಪ್ರಚೋದಿಸಿ.
ಉದಾಹರಣೆಗೆ, ಕನ್ಫರ್ಮೇಶನ್ ಇಮೇಲ್ ಅನ್ನು ಕಮಿಟ್ ಮಾಡಿದ ನಂತರ ಕ್ಯೂ (queue) ಮಾಡಿ, ಅದರ ಒಳಗಲ್ಲ:
$order = DB::transaction(function () {
// database work only
return Order::create([/* ... */]);
});
// Side effects happen after the database state is solid
OrderConfirmationJob::dispatch($order);
ಬಾಹ್ಯ ಕರೆಗಳನ್ನು (external calls) ವಹಿವಾಟಿನ ಹೊರಗೆ ಇರಿಸಲು ಎರಡನೇ ಕಾರಣವೆಂದರೆ: ಸಮಯ. ಒಂದು ವಹಿವಾಟು ಲಾಕ್ಗಳನ್ನು (locks) ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ ಅನ್ನು ಕಾರ್ಯನಿರತವಾಗಿರಿಸುತ್ತದೆ. ವಹಿವಾಟಿನ ಒಳಗಿರುವಾಗ Stripe API ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಮೂರು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಕಾಯುವುದು ಎಂದರೆ, ಮೂರು ಸೆಕೆಂಡುಗಳ ಅನಗತ್ಯ ಲಾಕ್ ಸಮಯ ಎಂದರ್ಥ. ವಹಿವಾಟನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಮತ್ತು ವೇಗವಾಗಿ ಇರಿಸಿ.
ಈ ಬಗ್ (Bug) ಏಕೆ ಅಡಗಿಕೊಳ್ಳುತ್ತದೆ
ಏಕ ಬಳಕೆದಾರ ಮತ್ತು ಸ್ಥಳೀಯ ಡೇಟಾಬೇಸ್ ಹೊಂದಿರುವ ಡೆವಲಪ್ಮೆಂಟ್ ಮೆಷಿನ್ನಲ್ಲಿ, ಸಂಬಂಧಿತ ಇನ್ಸರ್ಟ್ಗಳು (inserts) ಬಹುತೇಕ ಯಾವಾಗಲೂ ಯಶಸ್ವಿಯಾಗುತ್ತವೆ. ನೆಟ್ವರ್ಕ್ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ, ಡಿಸ್ಕ್ ಎಂದಿಗೂ ತುಂಬುವುದಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಸ್ಪರ್ಧಾತ್ಮಕ ಲೋಡ್ ಇರುವುದಿಲ್ಲ. ಕೋಡ್ ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡುವುದರಿಂದ ಅದು ಸರಿಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ.
ಪ್ರೊಡಕ್ಷನ್ (Production) ಪರಿಸ್ಥಿತಿ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಇಬ್ಬರು ಗ್ರಾಹಕರು ಸರಿಯಾಗಿ ಒಂದೇ ಮಿಲಿಸೆಕೆಂಡ್ನಲ್ಲಿ ಆರ್ಡರ್ಗಳನ್ನು ಸಲ್ಲಿಸುತ್ತಾರೆ. ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಸಮಯದಲ್ಲಿ ಕ್ಯೂ ವರ್ಕರ್ (queue worker) ಕೆಲಸದ ಮಧ್ಯದಲ್ಲೇ ಮರುಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಪೇಮೆಂಟ್ ಪ್ರೊವೈಡರ್ ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಟೈಮ್ಔಟ್ ಆಗುತ್ತದೆ. ವಹಿವಾಟುಗಳಿಲ್ಲದೆ, ಈ ಘಟನೆಗಳು ಅನಾಥ ದಾಖಲೆಗಳನ್ನು (orphan records) ಮತ್ತು ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದ ಒಟ್ಟು ಮೊತ್ತಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ, ಇವುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. ಅತ್ಯಂತ ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ, ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಫೀಚರ್ ಟೆಸ್ಟ್ಗಳು ಇವುಗಳನ್ನು ಅಪರೂಪವಾಗಿ ಪತ್ತೆಹಚ್ಚುತ್ತವೆ, ಏಕೆಂದರೆ ವೈಫಲ್ಯದ ವಿಧಾನವು ಸಮಯದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ ಹೊರತು ಸರಳ ತರ್ಕದ ದೋಷಗಳಲ್ಲ (logic errors).
ಪರಿಹಾರವು ಅಸಾಮಾನ್ಯವಾದುದಲ್ಲ. ಅದು ಯಾಂತ್ರಿಕವಾಗಿದೆ. ನೀವು ಎರಡು ಅಥವಾ ಹೆಚ್ಚಿನ ಸಂಬಂಧಿತ ಬರವಣಿಗೆಗಳನ್ನು (writes) ನೋಡಿದಾಗ, ಅವುಗಳನ್ನು ವಹಿವಾಟಿನೊಳಗೆ ಸುತ್ತುವರಿಯಿರಿ (wrap). ಕಾಲಾನಂತರದಲ್ಲಿ, ಇದು ಒಂದು ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡುವಷ್ಟೇ ಸ್ವಯಂಚಾಲಿತವಾಗಬೇಕು.
ಇದನ್ನು ಒಂದು ಸಹಜ ಪ್ರಕ್ರಿಯೆಯನ್ನಾಗಿ ಮಾಡಿಕೊಳ್ಳಿ
DB::transaction() ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದಿಲ್ಲ. ಇದು ಘಟನೆ ನಡೆದ ನಂತರ ಅರೆಬರೆ ಡೇಟಾವನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಗುಪ್ತ ಸಂಕೀರ್ಣತೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಾಚರಣೆಗಳ ಗುಂಪು ಒಂದಕ್ಕೊಂದು ಸಂಬಂಧ ಹೊಂದಿದ್ದರೆ, ಆರಂಭದಿಂದಲೇ ಅವುಗಳನ್ನು ಹಾಗೆಯೇ ಪರಿಗಣಿಸಿ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ನಿಖರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ನಿಮ್ಮ ಎರರ್ ಲಾಗ್ಗಳು ಸ್ವಚ್ಛವಾಗಿರುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅರ್ಧಕ್ಕೆ ನಿಂತ ದಾಖಲೆಗಳ ಸ್ಮಶಾನವಾಗುವುದಿಲ್ಲ.