Акция!  Домен 34 грн, домен 55 грн, домен  - 65 грн, домен  - 99 грн, домен  - 56 грн!, домен  - 425 грн!
Мы используем cookie-файлы
Для оптимизации работы нашего сайта мы используем cookie-файлы. Продолжая использовать сайт, Вы соглашаетесь с использованием cookie-файлов.
  • RUB
  • USD
  • EUR
  • UAH
Чат техподдержки
Вы являетесь клиентом?
  • +38(044) 392-74-33  Киев
  • +38(057) 728-39-00  Харьков
  • +38(056) 794-38-31  Днепр
  • +38(032) 229-58-93  Львов
  • +38(048) 738-57-70  Одесса
  • +38(093) 170-15-42  Life
  • +38(067) 400-88-44  Киевстар
  • +38(095) 630-90-82  MTC
  • +1(888)393-24-51  USA, Toll free
  • +44(131)507-01-14  Great Britain
  • +7(499) 348-28-61  Москва

Хостинг. Встречайте php 5.4

Форумы Хостинг Встречайте php 5.4
eugen
7 лет
хостинг: есть
домен: есть
Встречайте php 5.4
На всех серверах хостинга уже доступен релиз php 5.4.0
eugen
7 лет
хостинг: есть
домен: есть
PS. Поскольку он вышел только вчера, традиционно в нем могут быть ошибки.
Поэтому использовать рекомендуем пока только для тестирования
Rock-N-Roll
7 лет
хостинг: есть
домен: есть
Скажите, eugen, в php5 появилась функция file_put_contents(), идентична последовательным успешным вызовам функций fopen(), fwrite() и fclose() - как пишется в мануале. Но при записи в файл может возникнуть ситуация (особенно при большой посещаемости), когда копия скрипта (запущенная другим пользователем с временной задержкой в доли микросекунд, равной примерно времени выполнения одной функции скрипта) может запортить данные в этом файле (допустим это текстовый счетчик или небольшая текстовая база данных). Для предотвращения подобной ситуации придумали функцию flock(), которая блокирует записываемый файл. Но вот пишут об этой ситуации много и по-разному: одни говорят, что эта функция некорректно работает, другие - утверждают об обратном, ссылаясь на неправильное ее использование. Кому верить - непонятно, а на практике проверить - нереально. И вот придумали "интегральную" функцию file_put_contents(), которая якобы решает все эти проблемы.

Вы не могли бы мне "прояснить" этот весьма тонкий вопрос:

1. Корректно ли работает встроенная блокировка функции file_put_contents() в случае почти одновременного доступа к файлу нескольких копий одного и того же скрипта (в режиме записи).
2. Будет ли корректно работать блокировка, если возникла ситуация одновременного доступа к одному и тому же файлу, но из разных скриптов. Например, xml-файл конфигурации какого-либо приложения или тот же текстовый счетчик. Посетитель заходит на сайт - front-end скрипт обращается к файлу (и возможно в него что-то ещё и пишет). И, допустим, в этот же момент администратор сайта с помощью back-end скрипта изменяет в нем какую-либо информацию.
3. Что будет происходить со скриптом, который попытается обратиться к заблокированному файлу - он будет ждать "в очереди" или завершит выполнение с ошибкой?
4. Насколько эффективно использовать эту относительно молодую функцию (file_put_contents()) при работе с небольшими текстовыми базами данных?

Заранее благодарен.
eugen
7 лет
хостинг: есть
домен: есть
1,2) Разработчики php сами в документации пишут, что flock нормально не работает в multithreaded веб-серверах. Мы используем apache с prefork, который не использует потоки. php работает как fastcgi-wrapper, тоже без потоков. То есть, теоретически, у нас на серверах flock использовать безопасно. Но если речь идет о разработке переносимого кода, то нужно искать другие решения.

3) Зависит от того, как в скрипте вызван flock. Посмотрите в аргументах функции, там есть возможность блокироваться (ждать) или сразу вернуться в скрипт с ошибкой в случае уже установленной блокировки.

4) Функция далеко не молодая, как и php5. По эффективности думаю особой разницы между полной перезаписью файла file_put_contents и fopen/fwrite/fclose вы не заметите.
Rock-N-Roll
7 лет
хостинг: есть
домен: есть
Спасибо. Жаль, что до сих пор однозначного решения "без извращений" нет...

Честно говоря думал что функция file_put_contents() хоть немного "продвинулась", а не просто "fopen()+flock()+fwrite()+fclose()". Не вижу смысла тягаться с MySQL, если базу данных и базой данных толком-то назвать язык не поворачивается, когда в ней должно лежать всего-то около сотни элементов. Да и "мобильность" кода лучше - вся инфа в файлах. Но как оказалось, безопасная запись в файл до сих пор является проблемой. Разочаровали Вы меня :)

PS: Я извиняюсь, что я тут раздул не по теме.
Участвовать в общении на этом форуме могут только
зарегистрированные пользователи.

Если вы уже зарегистрированы Вам необходимо войти на форум.

Тема закрыта по истечению срока давности.