Yo.!не, конечно всю таблицу блокировать глупо - аукцион у меня синоним лота :)
Поэтому я и отвечаю для лота. Для "всемирного аукциона" даже блокировка лота может стать существенной неприятностью; лучше дать людям insert-ить биды или апдейтить каждому свой бид.

Yo.!а как тогда показывать актульного победителя и его ставку гораздо большему числу читателей ? вычислять каждый раз имхо несоизмеримо дороже выйдет ...
Вычислять каждый раз особой необходимости нет, эту информацию спокойно можно кэшировать. В онлайн-аукционе неизбежно будет пауза - минута или несколько минут - между последней ставкой и фиксацией результата. Соответственно, выдача лидера например с десятисекундной задержкой ничего существенно не изменит, и в любом случае такая система будет приятнее, нежели постоянные сообщения "вы не успели сделать ставку, другой уже поставил больше".

мнениеАргументацию я кажется приводил.
Где, простите? Максимум того, что Вы привели, это "если попробуете последовать вот этому намеку, сможете самостоятельно подтвердите мою точку зрения".

мнениеИли вы хотели что бы я вам statspack-и выложил?
Если у Вас есть под рукой система с аналогичной нагрузкой, было бы неплохо. Особенно интересной была бы строка "потери на мини-откатах" из этого отчета :)

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

мнениеКонкретных замечаний по поводу фактов изложенных мной от Вас лично небыло.
От Вас лично не было изложено конкретных фактов. Исключительно несколько общих слов.

мнениеНи одного из моих аргументов вы не опровергили (технически).
Технически, если Вы не в курсе, аргументы требуется сначала "обосновывать", и только после этого, может быть, "опровергать" ¹ .

¹ Аргумент - это "утверждение, выдвинутое в подтверждение другого утверждения" . До тех пор, пока аргумент-утверждение не обоснован, опровергать его необходимо не более, нежели любое другое необоснованное утверждение

мнениеМаксимум что я от вас слышал это про Фому и Ерему
Да и то, либо не поняли, либо не захотели понять.

мнениеа также Пока ограничусь констатацией того, что зря "не вызывает".
Если Вы вдруг пропустили при чтении часть того поста, на которое отвечаете чуть ниже в тексте, могу дать ссылку для более внимательного изучения: http://www.sql.ru/forum/actualthread.aspx?tid=397997&pg=3#3821492

мнение softwarerубедили меня, что моей изначальной фразы (про связь read consistency и подзапросов) Вы просто не поняли.
Привидите пожалуйста цитату из сообщения с Вашей фразой.
Да запросто. Вы сами цитировали эти слова пару страниц назад -

softwarer пару страниц назадУпоминание подзапроса здесь имхо не совсем к месту. Если это существенная часть Ваших рассуждений, подозреваю, Вы хотели рассказать не о мини-откатах, а о специфике read consistency в этом случае.

Впрочем, сейчас у меня есть впечатление, что тогда я подумал о Ваших знаниях излишне хорошо.

мнениеВ подтверждение Ваших слов о моей некомпетентности прошу привести цитаты где я был не прав.
Мое впечатление более вызвано отсутствием некоторых цитат. Скажем, Вы сказали: "откаты ловите здесь". Я ответил - "если специально не извращаться, их здесь не будет". И в ответ - тишина, никакого примера, когда их таки можно поймать в нормальной ситуации. Есть конечно и некоторые цитаты, например

мнение пару страниц назадИХМО read consistency здесь причина, а миниоткат следствие.

Из чего явно видно непонимание механики и предназначения мини-откатов. Чтобы закончить эту ветку, поясню:

- до тех пор, пока в Oracle не было read consistency, не было и использующих на эту концепцию механизмов, в частности мини-откатов

- когда read consistency появилась, появилась возможность обеспечить write consistency путем совместного использования read consistency и мини-откатов.

мнениеГде я допустил ошибки в деталях?
Хотя бы в том же совете ловить мини-откат в указанном Вами апдейте.

мнениеГде я сказал чушь?Цитаты , ссылки?
Уже отвечено выше.

Yo.!кешировать, сомневаюсь
Думаю, не имеет смысла искать истину - она зависит от постановки и условий задачи :)

Yo.!, да и пауза в минуту думаю не приемлимо.
Хм. Я почему-то уверен, что пауза будет больше. Просто представьте себе, что Вы покупаете например картину Рембрандта, и она уходит Вашему принципиальному сопернику из-за того, что Вы уронили мышку и не смогли нажать Ok :)

Yo.!а наблюдал за аукционном наименьшей суммы (выигрывает кто сделал наименьшую уникальную ставку), так там все веселье начинается за минуту до конца аукциона (лота), т.е. эта минута все и решает. еще прикольно что может выйграть случайная ставка из-за того, что остальные ставки оказались неуникальны :)
Судя по описанию, Вы говорите о весьма специфическом случае. На нормальных аукционах afaik торгуются до максимальной цены, а не до фиксированного времени завершения торгов.

DPHГм, я все пытаюсь понять, как скорость проведения update (и, соотвественно, модель блокировок) связна с задачей аукциона?
Хм. В той теме, что начало мнение, связь с задачей аукциона вообще постоянно теряется. Если помните, я еще первым же своим письмом на эту тему сказал, что тезис имхо не имеет отношения именно к этой задаче :)

DPHТам гораздо проще текущего победителя и всю локальную историю хранить и кэшировать на уровне сервера приложений (с разными очевидными стратегиями распределения нагрузки между серверами). А в БД в этом случае нужно только вставлять (без всяких блокировок) заявки игроков - да и то только в целях аудита и, при необходимости, восстановления после падения.
Я бы не стал выделять сервер приложения. Собственно я сказал насчет вставок и кэширования, а как именно делать это кэширование - имхо уже вопрос десятый.

DPHИ при таком подходе в качестве БД можно хоть MySQL использовать...
А об этом я говорил чуть ли не во втором посте этого топика :)

Yo.!сомневаюсь я что за "Рембранта" будет 1К конкурентных транзакций ..
Безусловно, это уже утрирование для усиления эффекта :) Согласитесь, "серьезные аукционеры" вряд ли захотят терять деньги из-за того, что кто-то не успел нажать на кнопку. Поэтому пауза будет, и будет достаточно длинной (так, чтобы желающий поставить успел это сделать, но участники торгов и особенно победитель не слишком раздражались ожиданием).

Yo.!конечно гадать что автор имел ввиду под аукционом смысла нет, но что бы он там не имел ввиду, миниоткатам там взятся неоткуда
Безусловно.

Хм. Лень читать все "то" обсуждение, начало, честно говоря, не впечатлило. Чем она подобна обсуждаемой, не понимаю (возможно из-за того, что таки не прочитал те пять страниц, но есть впечатление, что подобна только упоминанием слова Oracle).

Yo.!ну да, и решили, что грязное чтение в 21 юзать не серьозно ...
И главное - зачем грязное чтение, если задача элементарно решается путем select for update skip locked?

DPHГм, тут не просто кэширование, тут еще и актуально кэширование без персистанса, т.е. уже вне уровня БД.
Во-первых, "уже" вообще говоря не обязательно. Никто не мешает создавать объект в БД, но без персистанса.

Во-вторых, я согласен с тем, что с практической точки зрения так, как предлагаете Вы, будет вполне удобно, но тем не менее, не вижу здесь принципиальности. Можно кэшировать и в БД и с персистенсом, ничего страшного не будет (конечно, дополнительные расходы, но контролируемые и непринципиальные).