V&Nприступайте к работе, вы уже определились. и ни в коем случае не понижайте уровень транзакции. SERIALIZABLE - и всё.
А почему бы и нет? Из-за иррациональной боязни низкой производительности? ;)

Misha Tyurinв пг на сиквенсе нету блокировки.
вам уже сказали выше, можете явно сами сделать подобное на обычных блокировках.

В MS SQL тоже нет, например.

Misha TyurinВ случае SERIALIZABLE в общем виде они могут идти параллельно, так как могут не разделять ничего общего.

Ну да, я про это уже писал.

Misha TyurinТогда вам надо что-то общее им дать (явно или не явно, по предикатам). а если вам надо им дать общую блокировку, и вы это видите явно (сиквенс до этого использовали) -- то тогда зачем использовать сложную изоляцию.

Незачем, мне хотелось бы узнать эту последовательность, не изменяя её.

Misha TyurinУ вас, в блокировочнике, почти уверен, изменение сиквенса лочит всё на нём. -- это и есть явный лок
Нет, не лочит. В блокировочнике это работает за счёт того, что последовательность сериализации совпадает с последовательностью COMMIT-ов. Т.е. первым значение получит тот, кто блокирует (и тут же сделает COMMIT), а затем уже тот, кого он блокировал.

ЁшОна же очевидно будет ниже, придётся некоторые транзакции по несколько раз повторять из-за конфликтов сериализации.
Безусловно, будет! Так давайте всё на ассемблере писать! ;)

Даёшь READ UNCOMMITTED - главное считать быстро , результат не имеет значения! ;)

Если серьёзно, вопрос тут в том, будет ли производительность неприемлемо низкой, и стоит ли повышение производительности отсуствия гарантии консистентности.

Misha Tyurinкого блокирует то?

Другую транзакцию на том ресурсе, за который они конкурируют, конечно.

Misha Tyurinо какой консистентности речь?
вы можете хоть как-то её, хоть на пальцах описать?
О той, которая гарантируется SERIAIZABLE. Я не понимаю, зачем её описывать "на пальцах", когда в стандарте SQL чётко сказано, что это такое.

Misha Tyurinобновление счетов, делается консистентно между конкурируюшими трназкциями в режиме ридкоммитед, как раз за счет блокировок счетов/аккаунтов

Или не делается, от ситуации и метода изоляции зависит. Вы о каком READ COMMITTED говорите (версионный или блокировочный) и о какой ситуации? И, кстати, обновление счетов я привёл просто как пример, вопрос был общий.

Гость_0Не существует СУБД полностью поддерживающей стандарт, хотя бы по этому.

Ну и что? В части обеспечения изоляции существует немало СУБД, полностью поддерживающих стандарт, и PostgreSQL - одна из них.

Misha Tyurinчет у вас всё путается.

Почему это - у меня? ;)

Misha Tyurinкогда я говорю о уровне изоляции, я как раз имею ввиду sql и феномены, и я не вижу разницы в движке базы: версионник или блокировончик, -- это уже ваще не важно.

Как это неважно? В PostgreSQL на REPEATABLE READ ни одного из описанных в стандарте феноменов нет вообще, а в блокировочнике есть фантомы, и т.д.

Misha Tyurinв сиквелсервере, сиквенс генерится в момент коммита. это ваще к уровням изоляции уже имеет отдаленное отношение, так как это всё вне транзакции. подозреваю, что есть лок на фиксацию транзакции в журнал, вот там вы и лочитетсь. лок есть, но не явный опять.

Ещё раз - нет там никакого лока, и SEQUENCE я могу использовать как часть метода отслеживания порядка сериализации.

Misha Tyurin // лично не видел, нагуглил: http://msdn.microsoft.com/ru-ru/library/ff878091.aspx "Порядковые номера создаются вне области текущей транзакции. Они обрабатываются, когда выполняется фиксация или откат транзакции, использующей порядковый номер."

Просто неправильный перевод. Там написано вот что:

Sequence numbers are generated outside the scope of the current transaction. They are consumed whether the transaction using the sequence number is committed or rolled back.

То есть это внетранзакционный, неблокирующий механизм.

Misha Tyurinпо sql стандарту, кстати, постгресовый рипитаблрид как раз есть сикуель-сериалайзебл.

Ничего подобного! Всё это чётко описано как в стандарте, так и в документации:
http://www.postgresql.org/docs/9.4/static/transaction-iso.html

Misha Tyurinвы точно уверены какой уровень именно вам нужен и зачем. каких случаев вы хотите избежать?

Да, уверен. Я хочу избежать всех случаев, не разбираясь с ними. ;)
Цитата из той же ссылки:

Consistent use of Serializable transactions can simplify development. The guarantee that any set of concurrent serializable transactions will have the same effect as if they were run one at a time means that if you can demonstrate that a single transaction, as written, will do the right thing when run by itself, you can have confidence that it will do the right thing in any mix of serializable transactions, even without any information about what those other transactions might do.


Misha Tyurinсмотрите еще какой момент. если транзакции шли как (1,2,3), а потом мы их видим как (2,1,3), но при этом результат последовательного применения по обоим порядкам одинаков, то обо порядка удовлетворяют условию сериализации. вам какой из порядков надо?

Любой.

Misha Tyurinеще раз обращаю внимание! в вашем блокировочнике (почти наверняка) есть *лок* на сиквенсе! -- но он не на уровне транзакций, а в движке фиксации коммита.

Ещё раз обращаю Ваше внимание, что лока там нет .


Misha Tyurin2) либо (не явные локи) ВСЁ надо по дефолту в сериалайзебл, все совсем транзакции сериалайзебл и только такие.

но и во втором случае вы НЕ получите порядок физических коммитов, а получите лишь один из "последовательных порядков".

Я знаю это, и хочу знать, какой именно из "последовательных порядков" я получил в каждой ситуации, где это имеет значение.

Гость_0PgSQLanonymous, ну вообще то нет, read uncommitted в postgres нет. Не хотите объяснять - ваше дело, что мне вас заставлять что ли?

Ну вообще-то да, и READ UNCOMMITTED в PostgreSQL формально есть. Вот цитата из документации, кстати (выделение моё):

When you select the level Read Uncommitted you really get Read Committed, and phantom reads are not possible in the PostgreSQL implementation of Repeatable Read, so the actual isolation level might be stricter than what you select. This is permitted by the SQL standard: the four isolation levels only define which phenomena must not happen, they do not define which phenomena must happen.

думаеццакакбе праткически то, что миша привел в кач-ве перевода

Как бы нет.
They are consumed whether the transaction using the sequence number is committed or rolled back.


Перевод примерно такой:

Они потребляются (используются) независимо от того, выполнена ли фиксация или откат транзакции, использующей порядковый номер.

думаеццаоткуда взялось словцо "неблокирующий"

Это следует из документации MS SQL, например.

думаеццаиз того, что ты не видешь толстова суслека - не следует с неизбежностью не только того, что его там нет, но даже и какого-то оправдания завиральным завываниям "ещщщщщё расс", "обрайщаяю" и т.п..

А ты не хамить не можешь?

думаеццаИтак -- русурс -- присвоитель номера-- один, не бесконечно быстрый (по определению)
пользователей -- много (транзакции)
а где они толкаются -- прямо перед ресурсом, или в кордорчике доступа к оному [или даже реально на однем камешке в затылочек друг-друго ходят, изображая параллельность] -- дело десятое, главное что такое место есть. его не может не быть.

Да, синхронизационный примитив (mutex там или ещё что...) там есть, ради того, чтобы каждое получение значения давало следующий номер, а не дубликаты, но это не обычная блокировка, т.к. она тут же снимается по получению значения.

думаеццавам нужно переписать коммит пж так, чтобы он тоже совался к каокому-нито "неблокирующему" [т.е. короткоблокирующему-- на время доступа] ресурсу. и писал его значение кудыньть в.
начать и кончить

Нет, это не поможет, сколько можно повторять? В SSI последовательность сериализации не совпадает с последовательностью COMMIT-ов.

думаеццакстати, что txid относится к началу а не к концу, не имеет в случае честного бетонного и именно сериалайзебла никакой роли.
опять же если порядок требуется любой из возможных.
или я вру ?
ведь если вона коничла, то другие, позже стартовавшие, явно ей не помешали кончить.
и могут щитаццо более позжими.
( и если кончили, и если обломались)
и так -- с каждой парой */автор интересуется только конившими/
т.е. попарные сравнения заданы, и заданы непротиворечиво, аддитивно и перестановочно
нет ?
Нет. Прочитай раздел "Apparent Serial Order of Execution" по ссылке из первого сообщения темы.

anonymous anonymous а я маленькину какбе читателю анкомиттед интересна не буква стандарта, а что другие негодяи в запись-пись успели понаписать.
Пусть найдёт себе другой глобус, я считаю. ;)

anonymous anonymous а я маленькии пж--негодяи вполне могли бы такое под своей какоё-нить уровнёй реализнуть. если им шапка из стандарта не по нутру. поленились, ссуки
т.ч. комитеты такие комитеты

Они как-то это обсуждали, вот, например, мнение Tom Lane по этому поводу:
http://www.postgresql.org/message-id/5209.1211760608@sss.pgh.pa.us]http://www.postgresql.org/message-id/5209.1211760608@sss.pgh.pa.us

Или вот ещё: http://www.postgresql.org/message-id/AANLkTikLBFk4mE=fg18wLStLPwGJTEbOhS=sY5G9smgQ@mail.gmail.com]http://www.postgresql.org/message-id/AANLkTikLBFk4mE=fg18wLStLPwGJTEbOhS=sY5G9smgQ@mail.gmail.com

думаеццану если у вас проблемы с русски, и "или"[-или] в качестве либо-либо вас не устраивает, -- можешьте педалировать "независимость", педалик вы нашЪ

Понятно, не хамить не можешь. :( И полезного ничего не говоришь.
Наше общение, я, пожалуй, закончу на этом:

думаецца я спрашиваю о переводе конкретного предложения, и плыть в сторону океана доки абсолютно бесполезно. фиксирую -- опрашиваемый поплыл.


Оригинал:
They are consumed whether the transaction using the sequence number is committed or rolled back.

Перевод 1:
Они обрабатываются, когда выполняется фиксация или откат транзакции, использующей порядковый номер.

Перевод 2:
Они потребляются (используются) независимо от того, выполнена ли фиксация или откат транзакции, использующей порядковый номер.

Разница очевидна, IMHO.