не понимаю зачем мне это.
Выше же писал. Никакого отношение это не имеет к данной ситуации
я это понимаю, но почему-то же INSERT успешно проходит с дублем.
Значит ZP неправильно определяет результат запроса?
Выше же писал. Никакого отношение это не имеет к данной ситуации
Значит ZP неправильно определяет результат запроса?
RoyalBank
Client
- Регистрация
- 07.09.2015
- Сообщения
- 557
- Благодарностей
- 550
- Баллы
- 93
Одной строкой решаются все проблемы. И не нужно изобретать что-то, пытаясь понять, где косячит, зенка, база, запросы. Простой лок, все решает. Но если есть желание достучаться до правды, то можете продолжить поиски.
Делаешь ЛОК - берёшь акк меняешь у него СТАТУС, снимаешь ЛОК - решает кучу проблем и наглядно видно что бл*ть происходит с твоими юзерами!!!
Это чуть сложнее зато, нет такого гемора )
Это чуть сложнее зато, нет такого гемора )
- Регистрация
- 06.11.2018
- Сообщения
- 11 790
- Благодарностей
- 5 720
- Баллы
- 113
вообще-то в общий код.
а еще лок, это не блокировка списков. Это блокировка выполнения кода. Когда есть лок, другие потоки не работают, они ждут возможности зайти в лок. в этом месте где есть лок, всегда будет однопоток.
Тебе надо просто понять этот механизм. На текущий момент, ты его вообще не понимаешь.
такое ограничение не сработает, потому как 2 потока имеют разный pid. сократи до acc, state
объясни пож. не понимаю.
ты прав. Если знаешь как, то напиши пож
уникальный ключ порождает ограничение на возможность вставки записей с одинаковыми значениями. чем он шире, тем больше вариативность записей. твой ключ состоит из 6 столбцов, это значит, что сработает он лишь в случае попытки вставить запись с полным соответствием значений ранее вставленной записи
- Регистрация
- 06.11.2018
- Сообщения
- 11 790
- Благодарностей
- 5 720
- Баллы
- 113
дали же статью на охранный лок. там очень хорошо все расписано.
если в кратце, то вот весь лок
lock (SyncObjects.свой общий объект)
{
тута весь код , он выполняется в 1 поток для SyncObjects.свой общий объект
}
в общем коде можно на создавать локеров под любые задачи.
ты здесь что-то путаешь.
Специально создал новую таблицу и попробовал два запроса
INSERT INTO test (acc,info) VALUES ('5','111111')
INSERT INTO test (acc,info) VALUES ('5','222222')
всё отрабатывает правильно:
костыль вроде бы неплохой, вот только работает 2 сервера, т.ч. это не спасёт
нужно на уровне MySQL победить
покажи определение таблицы (show create table) и как выглядят 2 одинаковые записи в таблице
- Регистрация
- 24.10.2016
- Сообщения
- 6 518
- Благодарностей
- 3 370
- Баллы
- 113
Лок стоит делать на стороне базы данных. lock C# работает только в одном шаблоне, одного постера.
Последнее редактирование:
- Регистрация
- 06.11.2018
- Сообщения
- 11 790
- Благодарностей
- 5 720
- Баллы
- 113
насчет тостера не знаю.... разработчикам виднее что за тостер у них получился
такс... вот сразу возник вопрос. а чем отличается один поток одного шаблона от одного потока другого потока, если я у обоих прописываю один и тот же общий код и один и тот же общий объект.
например SyncObjects.MyLockSQL
у меня же будет работать лок правильно для этого SyncObjects.MyLockSQL во всех шаблонах одного "тостера" ? или же все таки не будет ?
- Регистрация
- 24.10.2016
- Сообщения
- 6 518
- Благодарностей
- 3 370
- Баллы
- 113
Тут решает объект lock'а. Что бы лок был на все шаблоны необходим объект на все шаблоны (или весь постер), например:
Snippets/Сниппеты/[Логика]/[Блокировка между потоками, шаблонами]/Объекты для синхронизации между шаблонами.cs at master · ZennoHelpers/Snippets · GitHub
Коллекция сниппетов пользователей ZennoPoster. Contribute to ZennoHelpers/Snippets development by creating an account on GitHub.
github.com
Snippets/Сниппеты/[Логика]/[Блокировка между потоками, шаблонами]/Синхронизация шаблонов через глобальные переменные.cs at master · ZennoHelpers/Snippets · GitHub
Коллекция сниппетов пользователей ZennoPoster. Contribute to ZennoHelpers/Snippets development by creating an account on GitHub.
github.com
никогда такого не было и вот опятьнасчет тостера не знаю.... разработчикам виднее что за тостер у них получился
Вроде как проблема решена.
По крайней мере ни одного дубля за последние 20 часов.
В виду того, что апи ресурса работает через левую кривую руку разработчика-дцпшника, которая торчит у него из 5ой точки, бывало такое, что поток на простейших моментах мог не отстукивать в базу больше 10 минут, а потом внезапно проснуться как протрезвевший бомж с утра и обнаружить, что аккаунт уже отобрал другой поток (т.к. у меня все, что > 7 минут считаются мёртвыми)
А при старте потока он чистит из online всю мертвячину.
После перехода на резервный апи всё ок.
Так что реализация с INSERTом без локов отлично отрабатывает как и задумывалось.
Ложная тревога.
По крайней мере ни одного дубля за последние 20 часов.
В виду того, что апи ресурса работает через левую кривую руку разработчика-дцпшника, которая торчит у него из 5ой точки, бывало такое, что поток на простейших моментах мог не отстукивать в базу больше 10 минут, а потом внезапно проснуться как протрезвевший бомж с утра и обнаружить, что аккаунт уже отобрал другой поток (т.к. у меня все, что > 7 минут считаются мёртвыми)
А при старте потока он чистит из online всю мертвячину.
После перехода на резервный апи всё ок.
Так что реализация с INSERTом без локов отлично отрабатывает как и задумывалось.
Ложная тревога.