Цитата:
Сообщение от Jocker
|
зачем использовать ранд? Да и еще от
нуля?
Объясняю:
1. Если попадется 0, то значит 100% попадание что запрос не выполнится. тада уже лучше делать mt_rand(1, 99). да и лучше использовать mt_rand() - работает в 4 раза быстрее (хотя бы поэтому).
2. Зачем вообще использовать ранд? Если хотите сделать отрыв, сделайте +10 или +50 как можно больше, чтоб наверняка.
Вывод:
как лучший вариант реализовать item_delay, но на сколько мне ясно, наврятли Вы это сделаете и навряли вообще обладаете знаниями в яве, а значит просите у кого-то за деньги или за спасибку.
Как вариант № 2 делаете так как я сказал, при неудачном запросе выполняется другой (100% ) запрос с инфой о попытке сдонатить в вашу табличку созданную. Там уже если будут жаловать, хотябы восстановить сможете.
Иные варианты (возможно бредовые) :
- Сделать цикл на выполнение при неудачке
- сделать +10 или 50 (чтоб наверника) в обжект_ид, но в случае если сборка заполняет пропущенные ид, что наврятли (уточняйте у ява кодеров). Предположим даже, если и не заполняет обж_ид пропущенные, то при высоком/активном онлайне это может грозить быстрым исчерпанием ИД (если конечно верить слухам, что ИД все таки скончаемый ).
Как работает чтение ИД на сервере Вы интересовались - так же как и на php вы делаете в запросе, считывается в базе максимальный ИД. ИМХО, других вариантов не вижу.
Добавлено через 6 минут
Цитата:
Сообщение от Jocker
диапазон от 500000000 до 599999999, его должно хватить. Длинна записи 9 символов- нормально, 1млрд записей думаю хватит на долго. Как думаете?
|
такое впечатление как будто Вы функцию рандом (случайный выбор от 0, 999.. ) принимаете как какой-то резерв для чего то.
Добавлено через 13 минут
Цитата:
Сообщение от Jocker
Ro_0TT, Вы пишете про item_delay, но тоже никаких аргументов, чем это лучше обработчика.
|
Это самый лучший вариант, даже не обсуждаеться. Объясняю как он работает.
Есть 2 таблицы:
- items (для хранения итемов)
- items_delay (для хранения
временных итемов)
Т. е. скрипт на php делает запрос в items_delay. Т. е. в эту таблицу запрос на инсерт делает только 1 поток - это внешний (в вашем случае php скрипт). Мы делаем запрос именно туда. Далее уже сервер через каждые 5 минут (может больше/меньше, хз ) делает проверку, есть ли в этой таблицы еще не розданные итемы. Если они есть, то он раздает их сам, т. е. сам обрабатывает. Тут сбоя просто не может быть. Как он проверяет раздавался ли итем - колонка status отвечает, при запросе скрипт делает Insert... status=0, а когда сервер уже обработал он делает UPDATE status=1. Думая ясно.