@Transactional, ஒரு method-ஐ ஒரு database transaction-இல் மடிக்கிறது: method இயங்குவதற்கு முன் Spring ஒன்றைத் திறந்து, அது இயல்பாக return செய்யும்போது commit செய்கிறது — அல்லது அது throw செய்தால் roll back செய்கிறது. உள்ளுக்குள் இது ஒரு AOP proxy ஆகும், இதுவே பெரும்பாலான gotcha-க்களின் மூலம்.
{
{
accounts.debit(from, amount);
accounts.credit(to, amount);
}
}
Default-ஆக Spring, unchecked exception-கள் (RuntimeException) மற்றும் Error மீது மட்டுமே roll back செய்கிறது — checked exception-கள் மீது அல்ல. நீங்கள் ஒரு checked exception-ஐ throw செய்தால், transaction commit ஆகிறது. அதை வெளிப்படையாக override செய்யுங்கள்:
@Transactional(rollbackFor = Exception.class) // roll back on checked too
public void process() throws IOException { /* ... */ }
ஒரு transactional method மற்றொன்றை அழைக்கும்போது என்ன நடக்கிறது என்பதை propagation தீர்மானிக்கிறது:
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void writeAuditLog(String event) { /* commits independently */ }
@Transactional ஒரு proxy வழியாகச் செயல்படுவதால், அதே class-இல் உள்ள மற்றொரு method-லிருந்து ஒரு @Transactional method-ஐ அழைப்பது proxy-ஐ தவிர்க்கிறது — annotation அமைதியாக புறக்கணிக்கப்படுகிறது. Bean-கள் முழுவதும் அழையுங்கள், அல்லது self-ஐ inject செய்யுங்கள்.
Data correctness வாழும் இடம் transaction-கள்தான், எனவே interviewer-கள் இங்கு கடுமையாக அழுத்துகிறார்கள். checked-exception rollback விதி மற்றும் self-invocation bug ஆகிய இரண்டு கேள்விகள், @Transactional-ஐ பயன்படுத்தியவர்களை, அதைப் புரிந்துகொண்டவர்களிடமிருந்து நம்பகமாகப் பிரிக்கின்றன.
விரிவான பதில்களுடன் கூடிய IT நேர்காணல் கேள்விகளின் நூலகம் — Junior முதல் Senior வரை.
நன்கொடை