http://sqlite.org/faq.html#q5

Именно сейчас нашему приложению безразлично, что там автор говорит. Но на будущее завели файл-флажок, база занята|база не занята. Поверили автору, боимся. Некрасиво получается. И смотрим на SQL Server CE. Там авторы не настолько категоричны.

Лично меня убивает читать, что “люди которые работали дофига на винде говорят, что блокировка глючна и ненадежна. Если это правда, то…” Как так можно в своем собственном FAQ? А? Проверь, а потом пиши, информируй.

Пользователей ~5, записей в день ~500.

Так можем ли мы безбоязненно использовать SQLite в сети для небольших таких, маленьких приложений? Кроссплатформенность важна. NFS, ага, всякое такое.

u4upy
Лично меня убивает читать, что “люди которые работали дофига на винде говорят, что блокировка глючна и ненадежна. Если это правда, то…” Как так можно в своем собственном FAQ? А? Проверь, а потом пиши, информируй.

В PHP есть функция стандартной библиотеки flock(), которая блокирует файл. Вот что написано в документации:

“Warning

flock() will not work on NFS and many other networked file systems. Check your operating system documentation for more details.

On some operating systems flock() is implemented at the process level. When using a multithreaded server API like ISAPI you may not be able to rely on flock() to protect files against other PHP scripts running in parallel threads of the same server instance!

flock() is not supported on antiquated filesystems like FAT and its derivates and will therefore always return FALSE under this environments (this is especially true for Windows 98 users).”

u4upy
Так можем ли мы безбоязненно использовать SQLite в сети для небольших таких, маленьких приложений?

Там где будет хоть маленькая конкуренция запросов к базе уже нужно начинать бояться =)

ну для сiткових цiлей краще firebird, ніж sqlite
http://www.sqlite.org/whentouse.html

або ж використовувати http://sqliteserver.xhost.ro/

http://sqlitedbms.sourceforge.net/index.htm

Ваш механизм блокировки будет очень похож на таковой в файловой 1С. Думаю, дальше объяснять нет смысла.

OS locks – весьма отвратительная штука. Имею что сказать по этому поводу. FAQ SQLite все правильно говорит.

Хотите кросс-платформенное решение? Чуть медленноватое правда. Так делается в bzr для создания замков. Алгоритм простой:

1. имеется каталог lock
2. в нем создается подкаталог со временным именем, в этом подкаталоге создается файл info с информацией о замке (например HOST/PID процесса, имя юзера, время создания замка). Наличие файла внутри каталога – важная деталь.
3. Затем временный подкаталог пытаемся переименовать в некоторое фиксированное имя, например held
4. Если переименование удалось – значит мы успешно закрыли замок
5. Если переименование не удалось, то значит другой процесс уже закрыл замок. Можно прочитать файл info, чтобы понять кто был этот наглец.
6. По окончанию блокировки каталог held удаляем вместе с файлом (или переименовываем во временное имя и удаляем).

Lexander
Ваш механизм блокировки будет очень похож на таковой в файловой 1С. Думаю, дальше объяснять нет смысла.

Почему же нет смысла? Очень даже есть. Не все тут эксперты по 1C. Расскажите, пожалуйста.

bialix
2. в нем создается подкаталог со временным именем, в этом подкаталоге создается файл info с информацией о замке (например HOST/PID процесса, имя юзера, время создания замка). Наличие файла внутри каталога – важная деталь.

почему важен файл внутри каталога? Он несет какую-то дополнительную нагрузку кроме того, что в нем лежит информация о том, кто залочил?
Что будет если процесс-локер упадет? наш лок будет вечно там висеть? Или нужно будет дополнительно проверять живой он или нет?

bialix
Файловые блокировки в 1С существенно сказываются на производительности. Причем, зависимость увеличения времени обработки 1-го справочника, документа от количества пользователей и объема БД - прямая.
Плюс проблемным местом именно под Вин является зависание или вылет клиента во время операций. Винда иногда забывает снять блокировку, даже если нет хозяина этой блокировки.

Ed

bialix
2. в нем создается подкаталог со временным именем, в этом подкаталоге создается файл info с информацией о замке (например HOST/PID процесса, имя юзера, время создания замка). Наличие файла внутри каталога – важная деталь.

почему важен файл внутри каталога? Он несет какую-то дополнительную нагрузку кроме того, что в нем лежит информация о том, кто залочил?
Что будет если процесс-локер упадет? наш лок будет вечно там висеть? Или нужно будет дополнительно проверять живой он или нет?

Файл внутри каталога нужен чтобы предотвратить успешное переименовывание на Linux-платформе. В случае пустого каталога операция может закончиться успешно даже если каталог уже существует.

Если процесс-локер упал или висит, то любой процесс может разрушить замок.