A local children's museum has an exhibit that shows how "email is sent through the internet". It uses a pneumatic tube system to shoot wooden balls from a sender through a series of clear tubes to a receiver. The balls go through various T-junctions, which makes the actual route taken "random", and these junctions are labeled with city names. Balls are released at such an interval that regardless of the route, they still arrive in the same order they were sent. A combination of black and white balls allows the recipient to verify the sender's message. There's even a little ascii-type chart to map color combinations to characters.
When my 4-year old saw and heard balls being shot around the wall-o-tubes, she said it was "the coolest thing she'd ever seen." We spent a good half hour feeding the machine.
(I don't know if copying someone else's museum exhibit would be legal, IANAL.)
I completely agree. The privacy aspects aside, this is Google making assumptions which are likely to be wrong. It's just like with their new fade-in homepage: they assume you're there to search, but when they're wrong, the end result is just frustrating.
iTunes LPs: These are effectively like bonus CDs for digital albums. Each one comes with extra songs that you only get if you plunk down nearly $20 on the whole album -- you can't download these individually. Along with that, you get video content -- in most cases, live concert recordings -- as well as photo albums and lyrics, which serve as a sort of modern-day liner notes, I guess? It's a bit like buying one of those loaded-up "Digipack" CDs record companies used to release, except on iTunes.
Good point. Instead of locking you can just do all the updates, and at the end update the version to 2 where version = 1. If this updates 0 rows, you need to roll back all of the updates and tell the user about the concurrent data change.
Even if they're atomic changes, and they both happen in sequence, the problem is that they both happen. The second user's data is stored, which means the first user's change was never seen by the second user and subsequently blindly overwritten.
There is one gap in this. If steps 3 and 5 happen at the same time, then steps 4 and 6 happen at the same time, and both User X and User Y could pass the "System checks whether incoming version matches database version" check. Some locking is still required, otherwise it will look to both Users as if they "won".
The method I'm most familiar with consists of 2 parts:
Each record[1] has a last_updated value associated with it.
Part 1: When a user loads the record for editing, it also loads the last_updated value. Upon submitting, the last_updated value is compared against the stored value and if they don't match this is considered a concurrency error. Exactly what happens depends on the nature of the record, but usually a message is shown to the effect of "the record was changed by someone else, please reload it and retry your edit." This is necessary to avoid problems when user B updates data between the time user A loads the data and submits their updates.
Part 2: At the exact moment when the submitted last_updated value is checked against the stored value, if the values do match then the stored value is locked for editing in the database.[2] For example via a "select for update" statement. Then the input is validated, the submitted data is stored, the last_updated value is updated, and all updates are committed, thereby releasing the lock. This is necessary to avoid problems when user A and user B submit their updates at almost the exact same time.
[1] "record" could be a logical record that consists of multiple physical records in the database. You'd need one last_update value per logical record. [2] In some cases you need to lock multiple locks when multiple separate records affect each other. Exactly when and how this needs to happen is left as an exercise to the reader.
2. With an uncanny knack for irony, Amazon recently remotely deleted any traces of certain electronic copies of George Orwell's "1984" and "Animal Farm" from customers' Kindles and iPhones, thereby sending these books down Orwell's so-called "memory hole."
WTF? Is this a legal complaint, or a sensationalistic blog post? I'd expect more professionalism from a law firm.
Slashdot Mirror
I for one welcome our...
No, it's nasty. I can't do it.
Fixed that for you.
He wants war games to get as close to real life as possible without any actual work, exertion, exercise, social interaction, or dirt.
inb4 not your personal army
Make of that what you wool.
First groan!
A local children's museum has an exhibit that shows how "email is sent through the internet". It uses a pneumatic tube system to shoot wooden balls from a sender through a series of clear tubes to a receiver. The balls go through various T-junctions, which makes the actual route taken "random", and these junctions are labeled with city names. Balls are released at such an interval that regardless of the route, they still arrive in the same order they were sent. A combination of black and white balls allows the recipient to verify the sender's message. There's even a little ascii-type chart to map color combinations to characters.
When my 4-year old saw and heard balls being shot around the wall-o-tubes, she said it was "the coolest thing she'd ever seen." We spent a good half hour feeding the machine.
(I don't know if copying someone else's museum exhibit would be legal, IANAL.)
Actually, support for extensions is part of the Windows and Linux betas.
I completely agree. The privacy aspects aside, this is Google making assumptions which are likely to be wrong. It's just like with their new fade-in homepage: they assume you're there to search, but when they're wrong, the end result is just frustrating.
You know what they say about assumptions...
Yes, don't hate me, I knew what I was doing. But I thought I'd share the fun of reading Benjamin Franklin's words in Vizzini's voice.
(...) Make a fmall crofs, of two light ftrips of cedar (...)
Awesome! I never knew old Benjamin had a lisp!
That depends. Kari, is that you?
Is that where they sell 0xBADC0FEE?
Assuming they make the missile 90% reflective so only 10% of the power burns a hole, where does the remaining 90% reflect to?
The interestingly named "Topless Robot"
*click*
Read the site. You'll know everything you need to know.
Phew! 2 hours later and only 51 comments. This must not be a big deal.
Y'all had me worried there...
Something tells me there's a nice investment opportunity in the Cardin, KS housing market...
What do ninjas have to do with Plancks?
Is this a pirate joke?
If not, it should be.
From gizmodo:
Good point. Instead of locking you can just do all the updates, and at the end update the version to 2 where version = 1. If this updates 0 rows, you need to roll back all of the updates and tell the user about the concurrent data change.
Even if they're atomic changes, and they both happen in sequence, the problem is that they both happen. The second user's data is stored, which means the first user's change was never seen by the second user and subsequently blindly overwritten.
There is one gap in this. If steps 3 and 5 happen at the same time, then steps 4 and 6 happen at the same time, and both User X and User Y could pass the "System checks whether incoming version matches database version" check. Some locking is still required, otherwise it will look to both Users as if they "won".
The method I'm most familiar with consists of 2 parts:
Each record[1] has a last_updated value associated with it.
Part 1:
When a user loads the record for editing, it also loads the last_updated value. Upon submitting, the last_updated value is compared against the stored value and if they don't match this is considered a concurrency error. Exactly what happens depends on the nature of the record, but usually a message is shown to the effect of "the record was changed by someone else, please reload it and retry your edit."
This is necessary to avoid problems when user B updates data between the time user A loads the data and submits their updates.
Part 2:
At the exact moment when the submitted last_updated value is checked against the stored value, if the values do match then the stored value is locked for editing in the database.[2] For example via a "select for update" statement. Then the input is validated, the submitted data is stored, the last_updated value is updated, and all updates are committed, thereby releasing the lock.
This is necessary to avoid problems when user A and user B submit their updates at almost the exact same time.
[1] "record" could be a logical record that consists of multiple physical records in the database. You'd need one last_update value per logical record.
[2] In some cases you need to lock multiple locks when multiple separate records affect each other. Exactly when and how this needs to happen is left as an exercise to the reader.
The glasses have a tiny adjustable slider on the bridge of the frame
Good thing the over-40 crowd is well-known for their dexterity and ability to accurately manipulate tiny adjustable sliders.
From the PDF:
2. With an uncanny knack for irony, Amazon recently remotely deleted any traces of certain electronic copies of George Orwell's "1984" and "Animal Farm" from customers' Kindles and iPhones, thereby sending these books down Orwell's so-called "memory hole."
WTF? Is this a legal complaint, or a sensationalistic blog post? I'd expect more professionalism from a law firm.