g
нет, если повторное использование сеансов включить в публикации
его еще нужно поддержать у вызываемое стороны
Size: a a a
2020 December 04
OT
В общем у него задача хранить какую то структуру в оперативной памяти сервера. Причем чтобы новый пользователь кто зашёл в 1с мог ее прочитать без дёрганья бд
мб через redis?
АМ
John Doe
Я его дал. Но ты почему-то проигнорировал.
видимо пропустил, ссылку дай пожалуйста
В общем у него задача хранить какую то структуру в оперативной памяти сервера. Причем чтобы новый пользователь кто зашёл в 1с мог ее прочитать без дёрганья бд
С утра еще предложили взять redis... но это ж сложнааааа
OT
С утра еще предложили взять redis... но это ж сложнааааа
ну блин
JD
1P
С утра еще предложили взять redis... но это ж сложнааааа
Мне интересно на чистой 1с сделать. Буду колдовать на выходных.
АМ
John Doe
а при чем тут время жизни сеансов? я ж ответил что время жизни сеансе сервиса настраивается и может быть сутки и более
JD
gosn1ck
его еще нужно поддержать у вызываемое стороны
Не нужно - все само
АМ
мб через redis?
с утра пропустил, сейчас посмотрю подойдет или нет. Спасибо.
АМ
Мне интересно на чистой 1с сделать. Буду колдовать на выходных.
мне не очень интересно делать на чистой 1с, но пока не вижу больше вариантов как это можно сделать быстро и на том что уже знаешь
Мне интересно на чистой 1с сделать. Буду колдовать на выходных.
Да конечно. Сначала соорудить костыль. Потом пройтись по граблям такого решения. Долго бороться и таки понять, что ненадежно / не масштибируется / нагрузку не держит и тд. Это явно быстрыее и проще, и для бизнеса дешевле будет, да.
JD
а при чем тут время жизни сеансов? я ж ответил что время жизни сеансе сервиса настраивается и может быть сутки и более
Наверное, при том же, при чем и твое упоминание какого-то "раз в сутки"
1P
с утра пропустил, сейчас посмотрю подойдет или нет. Спасибо.
Есть ещё какой то способ типа в оперативную память винды писать данные. И потом считывать от туда. Погугли. Может пойдет. Что то типа прокачаешь адрес памяти и в него пишешь. И любое приложение может от туда читать. А соответственно и сеанс. Но это внешнюю компоненту или ком соединение. А это плохо
H
Да конечно. Сначала соорудить костыль. Потом пройтись по граблям такого решения. Долго бороться и таки понять, что ненадежно / не масштибируется / нагрузку не держит и тд. Это явно быстрыее и проще, и для бизнеса дешевле будет, да.
И рано тли поздно такая таблица будет отличаться от реальных остатков.
H
Есть ещё какой то способ типа в оперативную память винды писать данные. И потом считывать от туда. Погугли. Может пойдет. Что то типа прокачаешь адрес памяти и в него пишешь. И любое приложение может от туда читать. А соответственно и сеанс. Но это внешнюю компоненту или ком соединение. А это плохо
В файлик на рабочий стол сразу
JD
И рано тли поздно такая таблица будет отличаться от реальных остатков.
А и не нужно дублировать запрашиваемую таблицу
1P
В файлик на рабочий стол сразу
В оперативную память быстрее ))))
JD
Кэшируются не запрашиваемые данные, а отдаваемый результат.
Плюс организуется надежное общение между сеансами, гарантирующее актуальность возвращаемого результата.
Все отдаваемые данные по-прежнему хранятся и обновляются только в одном исходном месте (БД 1С).
Плюс организуется надежное общение между сеансами, гарантирующее актуальность возвращаемого результата.
Все отдаваемые данные по-прежнему хранятся и обновляются только в одном исходном месте (БД 1С).
1P
John Doe
Кэшируются не запрашиваемые данные, а отдаваемый результат.
Плюс организуется надежное общение между сеансами, гарантирующее актуальность возвращаемого результата.
Все отдаваемые данные по-прежнему хранятся и обновляются только в одном исходном месте (БД 1С).
Плюс организуется надежное общение между сеансами, гарантирующее актуальность возвращаемого результата.
Все отдаваемые данные по-прежнему хранятся и обновляются только в одном исходном месте (БД 1С).
А это ты про что? Как это реализовать ? Какой способ?