Да я также думаю, передавать в мелкие методы транзакции благо они у меня как базовые методы взаимодействия с базой. Буду наследовать класс с мелкими методами для класса с крупными и передавая или задавая транзакцию для крупного метода мелкие методы будут выбирать альтернативное подключение как транзакция.
Протестил разные варианты:
Оказывается нет блокировки таблицы, блокировка идет как то на уровне библиотеки. Кака я это понял:
Стартанул проект и сделал два подключения к сайту через два разных браузера и учетки. Одна учетка дернула метод с транзакцией которая эмулировала долгую транзакцию, а вторая учетка сделала запрос к таблице и никакой блокировки. Даже если я в двух браузерах авторизуюсь под одной учеткой sql тоже нет блокировки тб.
Блокировка идет только из текущего запущенного потока подключения пользователя. Т.е. если запущена транзакция в работе и до коммита идет метод по подключению к базе, то этот метод коннектится к базе но запрос по таймауту вываливается, и чтобы это избежать нужно этот запрос включить в транзакцию. Заметил еще что это блокировка срабатывает когда были внесены изменения и эта блокировка распространяется только на текущий поток приложения. И такое ощущение что это не на уровне ядра блокировка ...
P.S. Повторюсь мелкие методы у меня подключаются не по ACID а обычным способом.
Спасибо за совет, сегодня провели анализ нагрузки и пришли к выводу, что из за роста объема данных некоторые тяжеловесные запросы стали нагружать sql. Пришли к выводу , что надо пытаться оптимизировать некоторые запросы и минимизировать запросы со стороны клиента когда данные ему вообщем то не нужны и грузить их лишний раз не стоит.
На счет уникально ID запроса ... тут я не знаю как прокомментировать. У нас в sql есть учетные данные входа по котором пользователь авторизуется и работает с базой, есть так же дефолтная учетка для неавторизованных пользователей. Все веб приложения используют учетные данные входа и тут я думаю нужно наверное какой то уникальный ID делать в связке приложение + учетка sql. Может это уже под капотом есть IIS + SQL пока не могу сказать. Не давать стакать запросы пока не завершиться первый ... ну это так бешенная идея
Akina, На уровне интерфейса это нереально. Заблокировать web интерфейс? Пользователь обновит страницу и повторит. Один вариант крутится в голове это сделать свой планировщик, но это геморно втискивать его уже в работающую систему.
Вы правильно сказали все, куча разрозненных операций, неконтролируемых sql. Весь контроль идет на бекенде (в коде) не в транзакциях
Akina, это вы говорите про полную транзакцию, которая проверяет и создает объект в одной транзакции. У нас все операции разбиты на мелкие транзакции. Транзакция на проверку, транзакция на запись, транзакция. Т.е. например таблица обджект обладает 5 поляуми. Объект заполняется не одним запросом, а мелкими. Например чтобы создать тело объекта, я проверю некоторое условие в базе, потом отправлю трнзакцию на создание объекта т.е. выдам ему ID потом имея ID создам в таблице Свойств уникальную пару ID, СВойство ID, и запишу например число. Как буд то вы работает с ООП. Мелкие запросы. Вот тут и возникает параллельный доступ к данным и коллизии.
есть главный объект (узел) у него дочернии объекты со своими свойствами. Свойства уникальны в пределах объекта. Т.е. уникальность на уровне свойств имеется. Уникальность у объекта только по id. Из за подвисуна может создасться два таких объекта. Потому что пользователь не дождался предыдущей транзакции, обновил страницу и нажал создать снова
У нас было раньше два сервера. Один из которых был старый и на нем были некоторые ресурсозатратные операции. Как то жили и вытягивали. Потом по определенным причинам, пришлось объединить базы на один сервер. И при разовой высокой нагрузке по расчету годовому, стали наблюдаться как раз таки проблемы. Что транзакция стала подвисать, а пользователь он такой неудержимый. Обновляет страницу и и снова создает запрос на создание объекта из за чего появляется ошибка по уникальному ключу
freeExec, пробовал код со статьи https://machinelearningmastery.com/how-to-develop-...
Multiple Parallel Input and Multi-Step Output т.е. подаю 1 семпл размерностью 100 получаю допустим семпл из 50 значений.
подключил свой датасет и loss уходит в Nun функция активации relu, поменял на tanh в nun перестало уходить, но все графики стали себя в какой то мере повторять разница только по высоте графика, но геометрически они себя повторяли. На форумах пишу либо это градиентный срыв либо в датасете есть значения Nun. Значений Nun нету проверял. Пробовал делать градиент отсечки 0.5, nun ушел но графики предсказанные такие себе .. все перетыкал даже не знаю где еще подробной инфы почитать
freeExec, так я подаю на вход вектор из 100 значений и жду одно. Потом собираю новый вектор из 100 но выкидываю первое значение и добовляю новое. И так далее добавляя в вектор новые предикты пока вектор полностью не заполнится только новыми значениями. Как будто то у меня уже был вектор из этих значений и я просто двигал окно на N+1 сто раз. Ведь тренинг так же работает у него есть допустим 990 семплов и в каждом последующем семпле окно сдвинуто на N+1. Только тут я делаю новый семпл сам потому что не имею следующих
freeExec, я оставлял 2 таких вопроса, но что то ответов нет либо ни кто толком не знает либо я как то плохо описывал что хотел. Ну вот смотрите у меня есть допустим 1000к датасет я его разбиваю на 990 семплов в каждом 100 значений сиквенции предсказание + одно число и на выходе я получаю (990,1 ) шейп с предскантем сетки. т. Е. Я могу в фит запихать всю выборку потому что знаю ее. П в случае с предсказанием за выборку Я могу подать в предикт только 1 семпл и получить 1 предик. Как получит N +2 число? А для этого формировал новый семпл с этим числом на конце и предсказывал новое и теперь уже два новых числа вхонце семпл и так добавлял новые предсказания в семпл пока оно полностью не заменится новыми предсказанными значениями. Суть такая что я вместо одного раза как в тренинге передав 990 семплов получал 990 предиктов делал итеративный вызыв предикт N кол-во раз чтобы получить N кол-ва предиктов.
Проблема в том что с тренингом предсказнте сети нормально но вот предсказание за датасет ужасное
Здравствуйте, у меня второй столбец это показания тока а первый вибрации, я беру окно размером N в котором col1: i ... i+100, col2: i...i+100 и прогнозирую на шаг вперед, таргет значение col1: i+101 и так далее.
Пример я брал с сайта https://machinelearningmastery.com/how-to-develop-...
Борис Животное, у меня таски лежат в массиве, и пока есть рабочая такска я не запускаю другие такски. Можно конечно с флагом сделать, но вот почему то решил так)
Протестил разные варианты:
Оказывается нет блокировки таблицы, блокировка идет как то на уровне библиотеки. Кака я это понял:
Стартанул проект и сделал два подключения к сайту через два разных браузера и учетки. Одна учетка дернула метод с транзакцией которая эмулировала долгую транзакцию, а вторая учетка сделала запрос к таблице и никакой блокировки. Даже если я в двух браузерах авторизуюсь под одной учеткой sql тоже нет блокировки тб.
Блокировка идет только из текущего запущенного потока подключения пользователя. Т.е. если запущена транзакция в работе и до коммита идет метод по подключению к базе, то этот метод коннектится к базе но запрос по таймауту вываливается, и чтобы это избежать нужно этот запрос включить в транзакцию. Заметил еще что это блокировка срабатывает когда были внесены изменения и эта блокировка распространяется только на текущий поток приложения. И такое ощущение что это не на уровне ядра блокировка ...
P.S. Повторюсь мелкие методы у меня подключаются не по ACID а обычным способом.