Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m interested in how database transactions “commonly” are implemented in a database system, like for instance MySQL.
Assuming the actual writing of data to the physical database storage isn’t an atomic operation (speaking in terms of clockcycles now), shouldn’t I be able to corrupt a transaction by for instance ripping the power cable at some carefully chosen moment?
If the database system is carefully written, there should be no point in time where power outage can corrupt data, and when power outage occurs, no committed data should ever be lost.
The rdbms writes data first to a transaction log before actually updating the data. After a crash, it replays the log, copying any pending changes from the log into the database, and rolling back any transactions which have not been completed in the log. Commit is reported as successful only after the hard disk has reported a completed write operation to the log.