"a database which uses optimistic concurrency in serializable isolation level. Postgres is often configured this way, though it's not the only way it can be configured."
It's not the default (read committed is) and I never saw serializable being set in actual production systems. You can do it, but then you have to be able to retry all of your transactions, including read.
What if the task you do take 5 minutes? 30 minutes? 10 hours? Do you create long transaction, blocking all reads?
> It's not the default (read committed is) and I never saw serializable being set in actual production systems.
It's not the common mode of deployment, but it's definitely in prod use.
> You can do it, but then you have to be able to retry all of your transactions, including read.
Pure read transactions shouldn't need to be retried in postgres due to serialization errors. You need to have read-write dependencies for that.
That's not to say that effectively read only transactions aren't affected by serializable, you do need to record the necessary metadata for the serialization logic to work.
FWIW, if you know your transaction is read only and long running, you can start a transaction with START TRANSACTION READ ONLY DEFERRABLE, which makes the start transaction slower, but then does not need to do any work related to serializable while the transaction is running.
> I never saw serializable being set in actual production systems
Every major prod system I've worked on in the last 15 years ran in serializable, including my current charge which processes tens of billions of dollars annually. YMMV but this is quite common in serious production systems. Google's Spanner only runs in serializable.
It doesn't matter though. I could write the sequence out with a SELECT FOR UPDATE and the second request will block instead of retry. The client experience is the same; the "second" request blocks. @pdonis wanted an example so I picked one.
It's just the horrible misapplication of the term 'stateless' to a wrapper around something very-much stateful. It's here to stay.
(Though I do disagree with the original premise too. Putting on a 'stateless' boxing glove won't mean there's no difference between punching a guy once or twice)
In my experience those people get juicy positions doing nothing useful as they their competence long atrophied due to zero pressure to keep their knowledge up to date. Of course now companies hire "consultants" to work around to issue, so those get fired on a week's notice when money is tight. The warm bodies remain in their chairs until retirement. Inefficiency remains a huge problem in Swedish economy, but no one dares to touch these archaic rules (BTW no minimal wage in a European country, WTF?) due to political reasons, so the immigrants get the blame instead for everything.
Unless you write everything from scratch, you are forced to deal with 20 years of bad design. I really wish people would just stop beating this dead horse.
A lot of de Java standard library is actually quite nice to program with. Of course there are less good parts, but Java is committed to compatibility so you can choose between dealing with an old design versus continually refactoring code to the standard of the day. I prefer having a choice.
As far as Java use in companies is an indicator, the horse is still running.
It's not the default (read committed is) and I never saw serializable being set in actual production systems. You can do it, but then you have to be able to retry all of your transactions, including read.
What if the task you do take 5 minutes? 30 minutes? 10 hours? Do you create long transaction, blocking all reads?
reply