Таблица с сообщениями чата (id, addtime, caption, ... прочие поля)

Клиенту отдаются сообщения с id больше, чем последнее ним вычитаное, либо не старше 15 секунд (если это перая вычитка).

Вроде всё просто, пока не вспоминаешь, что сообщение с id=7 может быть зафиксировано позже, чем сообщение id=9.
А значит прочитавший сообщения 6, 8, 9 никогда не увидит сообщения #7.

Сообщения в чат пишутся в транзакциях разного типа (согласно основной задаче) и изменить их не получится.

Как научиться вычитывать все сообщения не смотря на очередность комитов?

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

Ivan_Pisarevsky, addtime будет содержать время начала транзакции.
Значит история та же самая, что и с ID - сообщение с addtime=7сек комитися в 11 секунд, а последняя вычитка была в 9 секунд. Сообщение утеряно.

Вести учет вычитанных сообщений тоже головняк тот ещё. Для каждого юзера нужно хранить список ID и addtime сообщений.
При вычитывании новой пачки добавлять в эту очередь свежие сообщения и удалять устаревшие. Если хранить всё в memcached, для примера, то однозначно надо будет делать блокировку этой очереди на время вычитывания сообщений.

Блокировки будут для каждого клиента, что уже не так страшно, как сейчас лочится файлик при записи собщений )

Dimitry Sibiryakov, к такому решению пришел из-за транзакций. Чтобы не городить огород с синхронизацией сообщений чата с тем же файлом или каким-либо сервером очередей.
Чат - это часть онлайн игрушки. Много где по коду пишутся системные сообщения (не от игроков) в чат.

Мимопроходящий, опишите подробней, пжлст.

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

авторДелать БД центральным элементом системы чата - вообще архитектурная ошибка.
Если не сложно, подробней опишите, пжлст. Вопрос синхронизации транзакций в БД и, допустим, файлов на диске ставит в тупик. Как это вообще делается?

Модератор вася нажимает кнопку "зарегистрировать клан" на заявке пети.
Стартует обработка запроса регистрации (время т1)
Пока обрабатывается этот запрос, петя в другой транзакции вычитывает чат (т2).
И когда транзакция регистрации клана добавит в чат сообщение для пети "ваш клан зарегистрирован"... его уже никто не будет читать - петя запомнил, что он вычитал все сообщения по т2 включительно.

Почему чат в таблице? Чтобы писать в констекте транзакции и не заморачиваться синхронизацией чата на отдельном движке и движка игры (откатилась на конфликте операция - откатились и все отправленные сообщения в чат).

Dimitry Sibiryakov, я сервер приложений и пишу сейчас - нет на кого решение спихивать )

Смотрю на ветку и думку гадаю: это я такой тупой или это тупо спамеры "умничают". "Всё неправильно", "юзай семафор", "у тебя ничего не получится", "комит четыре секунды". Умники,ёпрст! Если бы я знал как это сделать, то я бы не писал на форум и не просил совета.

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

Филин Урфину-Джусу одни словом "солнце" подсказал как избавиться от сорняков. Тут, смотрю, весь форум сплошные филины )

Уважаемые филины, постарайтесь выдавить из себя чуть более расширенные ответы - не всегда получается с одного слова понять ваши глубоие мысли :)

Спасибо.
Модератор: Жаворонку рекомендую ознакомиться с сообщением 1991850

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

Я пять раз прочел ваши слова. Вы развернуто описали мою проблему.

Нельзя на основании последнего считанного идентификатора игнорировать предыдущие.
Вы совершенно правы - нельзя.

Как минимум, например, идентификатор нужно присваивать только в момент создания записи в чате, после чего тут же должен следовать коммит. А не заранее дать идентификатор, потом полчаса подождать, и делать коммит.
Ясное дело что идентификатор сильно "устареет". Вам это ведь вроде понятно из самого первого вашего же сообщения.
Да, мне это ясно. Это и есть моя текущая проблема. "после чего тут же должен следовать коммит" не катит. Практика показывает, что даже в зазор 20 мс пусть не часто, но регулярно успевают впихнутся сообщения и нарушить очередь.

Надо подумать, как выдаются эти самые идентификаторы? Вы в курсе, что они выдаются в монопольном режиме?
Так что, для имитации этого в чате сообщения тоже должны идти монопольно, или сериализуемо, одно за другим. И никаких параллельных транзакций или вставок (сообщений) быть не должно.
А как же параллелизм СУБД, транзакции и вот это всё? Ради одного чата высраивать в очередь все запросы? Я не могу на это пойти. Потому и решил запихнуть сообщения чата в таблицу в контекст параллельных транзакций. Чтобы запросы не тормозились на монопольной записи сообщений чата.

Даже если и не монопольно, все равно нужен алгоритм, который всегда доставит все новые сообщения.
В общем, с базой данных или без, человек должен в чате увидеть все сообщения, которые были написаны. Не может быть сообщения, которое пришло позже того, как сообщения вычитаны, и чтобы человек его не увидел.Именно за таким решением я и пришел на форум )

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

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

Точно так же как и фраза "СУБД тут нахер не нужна. пользуй семафоры, пиши в плоский файл.". Я слышал про семафоры в многопоточных приложениях. Но я никак не могу придумать, как они мне помогут в web-приложении писать в плоский файл.

Сейчас сообщения пишутся в плоский файл. Давно-давно был жуткий код, где "идентификатором сообщения" был unix_timestamp запроса к серверу. Терялась куча сообщений. Костылем в этот файл добавил ID с генератора БД. Глюки уменьшились, но все равно попадаются "состояние гонки" - сообщения пишутся в файл не по порядку выданых им ID и ломается вычитка данных.
Блокировать подолгу файл для "сериализуемой" записи я не могу - это очень дорогая для производительноти блокировка.

Потому я и решил перенести сообщения в БД - паралеллизм при записи и никаких блокировок. Нет рассинхронизации "закомитили в БД, но не смогли записать в файл". Теперь осталось правильно вычитать записаное.

Есть планка. Не выполнил ее - иди "расти". Согласен - форум этот читать/понимать сложно.