Question 1

When should I use a database transaction?

Accepted Answer

The rule is simple to state: use a transaction whenever two or more writes must either all succeed or all fail. If a partial result would leave your data in a state that should never exist, those writes belong in one transaction.

The classic example is moving a value between two records. Deducting from one and adding to the other are individually valid, but a failure between them destroys or invents value. Wrapping both in a transaction means a crash rolls back to the state before either happened.

Less obvious cases are just as important. Creating a record and its dependent rows together, updating a row and writing an audit entry, or consuming a queue item and recording the result all share the property that half of it is worse than none of it.

A transaction is not needed for a single statement, because individual statements are already atomic. It is also not the right tool for coordinating with systems outside the database. A transaction cannot roll back an email that has been sent or a payment provider that has been called, and holding one open across a network request is actively harmful, since it keeps locks and a connection occupied for the duration of something you do not control. The usual pattern is to commit first and record intent, then perform the external action separately with its own retry handling.

Two practical cautions apply. Long transactions increase lock contention and can block other writers, so keep them as short as correctness allows. And under concurrency the isolation level determines what a transaction can observe from others running at the same time; the default is often weaker than people assume, so operations that read a value and then write based on it may need explicit locking or a stricter level to be correct.

Question 2

What does ACID mean in databases?

Accepted Answer

ACID names four guarantees a database provides around transactions. Atomicity means all or nothing. A transaction that updates several rows either applies completely or leaves no trace. A crash

Question 3

What should you actually log, and what should you never log?

Accepted Answer

Log what you would need to diagnose a problem you cannot reproduce — and never log anything that turns your log store into a liability. Most logging is written for the moment it is added rather than

Question 4

What are the common caching strategies?

Accepted Answer

A small number of patterns that differ in who writes to the cache and when — and choosing the wrong one for your consistency requirements is where cache bugs come from. The read patterns:

Question 5

How to handle exceptions in Java?

Accepted Answer

Handling exceptions in Java is essential for robust applications. Use try-catch blocks, multiple catches, finally blocks, and custom exceptions to manage errors effectively.

Question 6

Should errors be exceptions or return values?

Accepted Answer

A genuine design disagreement rather than a settled question — and the honest answer is that the two approaches differ in what they make visible in the type system and what they make easy to ignore.

Question 7

What is the difference between rolling back and rolling forward?

Accepted Answer

Reverting to the previous version versus fixing forward with a new release — and which is appropriate depends on factors that are worth deciding before an incident rather than during one. Rollback.

Related Questions