@Transactional एका method ला database transaction मध्ये गुंडाळते: method चालण्यापूर्वी Spring एक transaction उघडते आणि तो सामान्यपणे return झाल्यावर 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 { /* ... */ }
एक transactional method दुसऱ्याला call करते तेव्हा काय होते हे Propagation ठरवते:
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void writeAuditLog(String event) { /* commits independently */ }
@Transactional proxy द्वारे चालत असल्याने, त्याच class मधील एका method मधून दुसऱ्या @Transactional method ला call केल्यास proxy वगळला जातो — annotation शांतपणे दुर्लक्षित होते. beans ओलांडून call करा, किंवा स्वतःला inject करा.
Transactions मध्येच data ची अचूकता वसते, त्यामुळे interviewers इथे जोरात दबाव आणतात. checked-exception rollback नियम आणि self-invocation bug हे ते दोन प्रश्न आहेत जे @Transactional वापरलेल्या लोकांना ते समजणाऱ्या लोकांपासून विश्वसनीयरित्या वेगळे करतात.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या