@Transactional کسی method کو ایک database transaction میں لپیٹتا ہے: Spring method چلنے سے پہلے ایک کھولتا ہے اور جب یہ عام طور پر واپس آتا ہے تو commit کرتا ہے — یا اگر یہ throw کرے تو rollback کرتا ہے۔ پردے کے پیچھے یہ ایک AOP proxy ہے، جو زیادہ تر گڑبڑوں کا ماخذ ہے۔
{
{
accounts.debit(from, amount);
accounts.credit(to, amount);
}
}
بطورِ default Spring صرف unchecked exceptions (RuntimeException) اور Error پر rollback کرتا ہے — checked exceptions پر نہیں۔ اگر آپ کوئی checked exception throw کریں، تو transaction commit ہو جاتی ہے۔ اسے واضح طور پر override کریں:
@Transactional(rollbackFor = Exception.class) // roll back on checked too
public void process() throws IOException { /* ... */ }
Propagation یہ طے کرتا ہے کہ جب کوئی transactional method کسی دوسری کو کال کرے تو کیا ہوگا:
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void writeAuditLog(String event) { /* commits independently */ }
چونکہ @Transactional ایک proxy کے ذریعے کام کرتا ہے، ایک ہی class میں کسی دوسری method سے کسی @Transactional method کو کال کرنا proxy کو نظرانداز کر دیتا ہے — annotation خاموشی سے نظرانداز ہو جاتا ہے۔ beans کے پار کال کریں، یا self کو inject کریں۔
Transactions وہ جگہ ہیں جہاں data کی درستگی رہتی ہے، اس لیے interviewers یہاں سختی سے دباؤ ڈالتے ہیں۔ checked-exception rollback اصول اور self-invocation bug وہ دو سوال ہیں جو قابلِ اعتماد طور پر ان لوگوں کو جنہوں نے @Transactional استعمال کیا ہے ان سے الگ کرتے ہیں جو اسے سمجھتے ہیں۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں