бесконечно долбиться к занятым данным и "висеть"? Это вы называете бест прэктис в архитектуре БД? Это уж точно антитребования какие-то
не бесконечно, а пока не получится
О-хо-хо. :( Т.е. Вы этих принципов не знаете. :( (А ведь это не какие-то там "best practice", это просто основы.) Я поэтому в начале дискуссии и спрашивал, где Вы (всему) этому научились. > А если SLA отдачи всей страницы 30 секунд СУБД общего назначения не являются real-time, и никаких гарантий времени отклика в принципе не дают. Если у кого-то есть такое требование, ему придётся использовать какой-то другой инструмент, в худшем случае. > Если у принципов нет названий - очень похоже, что это доморощенные принципы Да Вы что? ;) Вот из "доморощенного" ISO SQL: "4.36.5 Implicit rollbacks The execution of a <rollback statement> may be initiated implicitly by an SQL-implementation when it detects the inability to guarantee the serializability of two or more concurrent SQL-transactions. When this error occurs, an exception condition is raised: transaction rollback — serialization failure." А вот описание принципов из "доморощенной" документации PostgreSQL: "When an application receives this error message [serialization failure], it should abort the current transaction and retry the whole transaction from the beginning." "...it is important that any data read from a permanent user table not be considered valid until the transaction which read it has successfully committed..." Ну и т.д. И вообще в любой многопользовательской ACID SQL СУБД действуют всё те же принципы.
Обсуждают сегодня