One thing I didn’t quite catch was: I thought most write transactions needs consistent reads on many (contended) “objects”, but the actual writes are often just one or two objects. Is 2PL addressing this or does a write transaction take write locks on all objects?
50 years later, is two-phase locking the best we can do?
21–30 of 87 posts
Re: 50 years later, is two-phase locking the best we can do?
#22I wonder how this new approach compares to serializable snapshot isolation (SSI)
https://wiki.postgresql.org/wiki/SSI
I'm not familiar with these technologies, but when I was studying databases, SSI was touted as the "better" 2PL on the horizon. I wonder how SSI compares to 2PLSF, and why it wasn't mentioned here?
Re: 50 years later, is two-phase locking the best we can do?
#23Earlier quoted context omitted.
I would use a ULID rather than thread ID. https://github.com/ulid/spec They (and others) are great for this kind of case - and many others.
ulid is great, I use it a lot. There is also a draft to make a new uuid variant – uuid v7 – that will be very similar to how ulid works. https://www.ietf.org/archive/id/draft-peabody-dispatch-new-u...
I use ULID a lot too and It’s frustrating how close the new spec UUIDs are to it without actually being the same… so I’ve got a bunch of code to modify once Postgres supports generation of the new UUIDs server side without extensions or stored procedures. Relatively painless work, but frustrating since it could have been avoided.
Re: 50 years later, is two-phase locking the best we can do?
#24Earlier quoted context omitted.
ulid is great, I use it a lot. There is also a draft to make a new uuid variant – uuid v7 – that will be very similar to how ulid works. https://www.ietf.org/archive/id/draft-peabody-dispatch-new-u...
I use ULID a lot too and It’s frustrating how close the new spec UUIDs are to it without actually being the same… so I’ve got a bunch of code to modify once Postgres supports generation of the new UUIDs server side without extensions or stored procedures. Relatively painless work, but frustrating since it could have been avoided.
Yes. V7 looks good but ULID already does it. Rather than change code, I'm just staying with ULID. All give us 128 bits. That should be enough for anyone ;/
Re: 50 years later, is two-phase locking the best we can do?
#25One thing I didn’t quite catch was: I thought most write transactions needs consistent reads on many (contended) “objects”, but the actual writes are often just one or two objects. Is 2PL addressing this or does a write transaction take write locks on all objects?
You can take locks on all objects before you write. Most systems don’t do that.
Usually there are multiple writes to complete a business process. In each step stale data is read to create a write request similar to how you place your order with the wait staff at the restaurant. The wait staff will orchestrate your request. First the chef prepares your meal according to the order ticket. Second the wait staff delivers your meal based on the chef’s internal work order. Lastly they take your payment based on the original order ticket. Notice there are at least three microtransactions based on stale data. No one is holding locks until the diner finishes eating.
Re: 50 years later, is two-phase locking the best we can do?
#26huh? no mention of serializable snapshot isolation (SSI), used by most commercial dbs for years. what gives?
Re: 50 years later, is two-phase locking the best we can do?
#27Interesting re the transaction ID generation. Sled generates ~70-120 million transaction IDs per second. The author points out that it’s still a scaling bottleneck but I wonder if Sled’s approach might raise the TPS for the contended case.
Re: 50 years later, is two-phase locking the best we can do?
#28I wonder how this new approach compares to serializable snapshot isolation (SSI) https://wiki.postgresql.org/wiki/SSI I'm not familiar with these technologies, but when I was studying databases, SSI was touted as the "better" 2PL on the horizon. I wonder how SSI compares to 2PLSF, and why it wasn't mentioned here?
I’m working on a memory model for a new platform which is almost entirely based around copy on write, snapshots and SSI. But in distributed effects you still need locks and two phase transactions and so on. These are largely complementary features imo.
Re: 50 years later, is two-phase locking the best we can do?
#29Isn’t 2PL a limited applicability construct?
All my incoming and outgoing “transactions” are over loosely-coupled API calls.
Is there a point I’m missing?
Re: 50 years later, is two-phase locking the best we can do?
#30Isn’t 2PL a limited applicability construct? All my incoming and outgoing “transactions” are over loosely-coupled API calls. Is there a point I’m missing?
IMO it’s about what’s happening underneath those API calls. You might be doing lots of POST requests that touch the same underlying sql table.