>flock - это еще не значит что никто к этому файлу не обратится пока он используется другими
А что же это значит?
а то, что flock ничего физически не запирает - это как договоренность, мол я работаю не лезьте. Если к "закрытому" файлу обратится кто-то не использующий функцию flock при открытии, то он доступ к нему получит без проблем.
Кроме того, нельзя использовать flock пока вы не открыли файл, т.е.
1 открываем
2 потом flock
а между первой и второй - есть промежуток небольшой
за который "возможно" сделать что-то не то. Некоторые поэтому делают иначе - открывают пустой файл-локер, его flock, а потом открывают уже рабочий файл
open(L, ">lock.lock")||die("Error:$!");
flock(L,2);
open(DB, "
...
close DB;
close L;
Об этом подробно и с примерами тут:
http://www.samag.com/documents/s=4075/sam1013019385270/sam0203i.htm>а операция довольно продолжительная,
или сам процесс запирания продолжительный? Сколько и почему? И как обходится Windows без этого запирания?
нет. Подразумевалась работа с данными.
Можно действительно все в переменную скинуть и закрыть, и когда данных немного, то это нормально. Но если БД большая, то грузить все в память - это не всегда удачное решение, иногда занимаются построчным считыванием и сразу делают то или иное действие, значит файл будет занят долго.
а Win..
в 9x нету, но наверняка они там что-то свое придумали но никому не сказали. Можно переименовывать lock файл и проверять переименован он или нет (т.е. альтернатива - флок поставлен или нет)
Нужно в цифрах оценить насколько, и сколько потом это улучшение будет стоить, и только тогда можно о чем-то судить, да и то для данного конкретного случая. И может эффективнее решить проблему скорости со стороны харда - уж очень быстро все дешевеет.
в цифрах то можно Benchmark.pm
все-таки все зависит от того, что нужно. А то что все дешевеет - так это можно и иначе смотреть, например раньше MySQL предлагали существенно меньше хостеров в тарифных планах чем сейчас, а сейчас почти что обязательно суют по умолчанию
Довольно "жесткая" логика у текстовых БД
А конкретнее, это интересно.
все критично зависит от того, насколько сразу все спланируется. Это конечно относится ко всем БД, но с SQL базами можно выкрутится за счет гибкости самого языка SQL, а вот в случае с текстом - все думаете вы, все выборки алгоритмы записи, обновление, разбивку полей делаете тоже вы.. и если вдруг понадобится ввести новое поле, или нужно будет добавить сортировку по какому-то полю то могут возникнуть сложности со встраиванием этих "дополнительных" возможностей в скрипт.
А есть же и альтернативы:
DBM (DB_File.pm, BerkeleyDB.pm) кстати их можно и в текстовые файлы кидать, если задать тип ДБ RECNO (правда у DBM с блокировкой не лучше дело обстоит, чем у текстовых БД)
(у других DBM администраторов ограничения на размер записи 1-5кб)
Можно на текстовых БД сделать и SQL базу DBI+DBD::CSV (громоздко правда)
