Pull to refresh

Comments 15

Фреймворки могут предоставлять спец.функции для работы с сессиями, следовательно, там это все может быть учтено ;)
Про «всецело полагаетесь на авторов» неспроста написал: например, в CodeIgniter по умолчанию именно session_auto_start, и в их index.php, являющийся по совместительству бутстрапом, начинающему девелоперу на CI заглядывать вроде бы и без нужды.

Ну а если с головой, и есть дополнительные возможности от фреймворка — вполне можно избежать различных неприятностей :)
При этом объекты в сессиях в CI прекрасно себя ведут.
Если вы об этом:

codeigniter.com/user_guide/libraries/sessions.html,

то по умолчанию эта «сессия» — куки (что несколько печально), в другой реализации — самостоятельная сессия фреймворка (таблица в БД, см. всё ту же ссылку), но к сессиям самого php (о которых речь в заметке) это, в любом случае, отношения не имеет.
Зачем вы тогда вообще упоминули CI:) Стандартные сессии в CI не используются вообще. Сессии в куках большой изврат, поэтому остается юзать только сессии в БД или игнорировать цишную библиотеку и юзать стандартные сессии. Да кстати с точки зрения объектов в сессии не вижу разницы между стандартными сессиями и сессиями в CI в любой их реализации.
Стандартные сессии в CI не используются вообще.

Спорно. Ведь $_SESSION никто не запрещает заюзать только из-за использования CI. И не я один это таки использовал.

Сессии в куках большой изврат, поэтому остается юзать только сессии в БД или игнорировать цишную библиотеку и юзать стандартные сессии.

О, вот вам и тот самый вариант, как под CI вполне обоснованно могут понадобиться обычные сессии от php, что я, собственно и наблюдал.

Собственно, «сессии» CI применительно к теме статьи — это таки оффтопик, или практически на грани: я всё-таки о стандартном $_SESSION и обертках для него писал.
CI поддерживает шифрование сессий хранящихся в куках с помощью библиотеки mcrypt.
до сих пор я не встречал ситуации, где мне понадобилось бы хранение объекта в сессии
Да, плохая практика. Есть у нас один проект, который писали потомки индийских мудрецов. Так вот там в сессии тоже хранили объекты. Пришлось немало повозится, чтобы пофиксить сей шедевр инженерной мысли, который приводил к рандомным вылетам авторизации пользователей на сайте из-за переполнения сессии.
А вот это уже — «переполнение сессии» — интересно. В каком смысле — вроде ж размеры файла под сессию не ограничены, или направили сессию в БД с недостаточно большим полем в таблице?

Продвинутые мудрецы все-таки должны предусматривать примерно максимальный размер своих данных :)
Сессии были реализованы свои. Храние — база. Максимальны размер — 4000 символов. Массивы данных сериализировались и запихивались туда. Получалась такая ситуация, что сериализированный массив занимал больше, база его резала и соответственно десериализация была невозможна. Так как 4000 сивмолов было явным перебором, пришлось переделывать механизмы работы и вычищать кучи мусора, которые пихались в сессию но не использовались. Вообщем бредовый был код. Сейчас храним там только самое необходимое (пара айдишников и флагов).
с точки зрения HighLoad, хранить мало того еще и не нативные сессии в базе данных совсем не хорошо
Да, вы правы. Но в нашем случае хранение нескольких параметров в базе при таких сессиях незаметно. Кластер этой нагрузки даже не замечает.
имхо для этого лучше подойдет memcached который собственно и предназначен для хранения любых объектов
ну не так и любых — в смысле, любых, но сериализированных :)
Sign up to leave a comment.

Articles