@Transactional किसी method को एक database transaction में लपेटता है: Spring method चलने से पहले एक transaction खोलता है और सामान्य रूप से return होने पर commit करता है — या यदि यह throw करता है तो roll back करता है। पर्दे के पीछे यह एक AOP proxy है, जो अधिकांश gotchas का स्रोत है।
{
{
accounts.debit(from, amount);
accounts.credit(to, amount);
}
}
Default रूप से Spring केवल unchecked exceptions (RuntimeException) और Error पर roll back करता है — 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 किसी दूसरे को call करे तो क्या होगा:
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void writeAuditLog(String event) { /* commits independently */ }
चूँकि @Transactional एक proxy के ज़रिए काम करता है, एक ही class में एक @Transactional method से दूसरे को call करना proxy को bypass कर देता है — annotation चुपचाप नज़रअंदाज़ हो जाता है। beans के आर-पार call करें, या self inject करें।
Transactions वहाँ हैं जहाँ data की शुद्धता (correctness) रहती है, इसलिए interviewer यहाँ ज़ोर से धकेलते हैं। Checked-exception rollback नियम और self-invocation bug वे दो प्रश्न हैं जो भरोसेमंद ढंग से उन लोगों को — जिन्होंने @Transactional उपयोग किया — उनसे अलग करते हैं जो इसे समझते हैं।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें