A disk sector is the smallest unit we typically work with for disk drives and SQLite keeps the journal header on its own sector. Then we specify the sector size of 0x00000200 (or 512). Since this is the first transaction, our database was empty before the transaction. Next, we have 0x00000000 which is the size of the database before the transaction started. SQLite has some journal modes where it'll overwrite the journal instead of delete it so the checksums help SQLite know when its working with contiguous set of entries and not reading old entries left behind from previous transactions. The value 0xf65ddb21 is called a nonce and it's a randomly generated number that we'll use to compute checksums for our entries in the journal. The first 12 bytes are filled with zeros but they'll be overwritten at the end of our transaction so let's skip them for now. If anything goes wrong before we get to the end, we can use the journal to put the database back in its previous state. It records the state of the database before any changes are made. The internal state of the sandwich shop is restored to how it was before the order started. If the sandwich maker gets to the cheese step and realizes they're out of cheese, they can tell you they can't make the sandwich and then put the ham and bread back where they found it. You either get a sandwich or you don't.īut behind the counter, there are multiple steps involved: grab the bread, add the ham, add the cheese, hand it to the customer. If you order a ham-and-cheese sandwich, you won't receive just a slice of ham or two pieces of dry bread. When you go to a sandwich shop, you walk up to the counter, announce your order, and you get a tasty sandwich in hand a short time after. So let's use a better example that involves our favorite topic: sandwiches. This example gets trotted out because atomicity is so unusual in the physical world that it's hard to find anything else that's as intuitive to understand.īut it turns out that atomicity doesn't "just happen" in databases either. Both actions must happen or neither must happen. All for One, or None at AllĮvery textbook definition of transactions involves a bank transfer where someone withdraws money from one account and deposits in another. The "C" stands for consistency but that doesn't involve the rollback journal so we'll skip that. Those make up 3 of the 4 letters of the ACID transactional guarantee that every database blog post is required to mention. This is called isolation.įinally, we need to make sure bytes actually get flushed to disk. The database needs to ensure each transaction has a snapshot view of the database for its entire duration. If another process is querying the database, it'll have no consistent view of the data since you're overwriting pages willy-nilly. This is called atomicity.īut that's not all. The database needs to ensure that all page writes for a transaction either get written or don't. If your server suddenly shut down halfway through a page write then you'll end up with a corrupted database. However, that 1% of the time is catastrophic. If you tried to overwrite a page in your database file directly, it would work fine 99% of the time. Any time you make a change-even a 1 byte change-SQLite will write a full 4KB page. In the last post, we talked about how SQLite is split up into 4KB chunks called "pages". To understand why you need a database journal, let's look at what happens without one. Today we're diving into the rollback journal: what it is, how it works, and when to use it. It has two different modes: the rollback journal & the write-ahead log. In order not to lose any of it when a transaction goes wrong, SQLite implements a journal. I've written before about how SQLite stores your data. However, in reality, the best database vendors tell you exactly how their database will lose your data. That's what a database is supposed to do. When database vendors recite their long list of features, they never enumerate "doesn't lose your data" as one of those features. Give us a whirl and get up and running quickly. Sometimes those containers run SQLite and we make that easy too. Fly.io runs apps close to users around the world, by taking containers and upgrading them to full-fledged virtual machines running on our own hardware around the world.
0 Comments
Leave a Reply. |