質問するログイン新規登録

回答編集履歴

2

補足

2016/10/08 22:27

投稿

popobot
popobot

スコア6588

answer CHANGED
@@ -19,4 +19,6 @@
19
19
  > 以前,「ロックなんておまじないみたいなもんだから別になくてもいい」と言われたことが有ります.本当ですか?
20
20
 
21
21
  厳密には、アクセス数に関係なく、同時にアクセスされる可能性があるなら、ロックは必要です。
22
- ただし、1日100件ですし、書き込むデータの少ないので、それほど同時に書き込みが発生するのは少ないとは思います。なお、ロックしない場合、同時に同じ位置から書き込みが起こるので、先に書いたデータを後に書いたデータで上書きされてしまうので、データが一部なくなったり、データが途中で上書きされたりするリスクがあります。
22
+ ただし、1日100件ですし、書き込むデータの少ないので、それほど同時に書き込みが発生するのは少ないとは思います。なお、ロックしない場合、同時に同じ位置から書き込みが起こるので、先に書いたデータを後に書いたデータで上書きされてしまうので、データが一部なくなったり、データが途中で上書きされて、CSVとしてもおかしなデータができるリスクがあります。
23
+ ロックしなくていいかどうかは、これらを踏まえて、最悪のケースが起きても、業務上問題ないのかどうかによると思います。
24
+ fcntl以外の方法としては、MySQLなどのDBに一旦しまうという方法が一般的ですかね。

1

誤字

2016/10/08 22:27

投稿

popobot
popobot

スコア6588

answer CHANGED
@@ -19,4 +19,4 @@
19
19
  > 以前,「ロックなんておまじないみたいなもんだから別になくてもいい」と言われたことが有ります.本当ですか?
20
20
 
21
21
  厳密には、アクセス数に関係なく、同時にアクセスされる可能性があるなら、ロックは必要です。
22
- ただし、1日100件ですし、書き込むデータの少ないので、それほど同時に書き込みが発生するのは少ないとは思います。なお、ロックしない場合、同時に同じ位置から書き込みが起こるので、先に書いたデータ後に書いたデータで上書きされてしまうので、データが一部なくなったり、データが途中で上書きされたりするリスクがあります。
22
+ ただし、1日100件ですし、書き込むデータの少ないので、それほど同時に書き込みが発生するのは少ないとは思います。なお、ロックしない場合、同時に同じ位置から書き込みが起こるので、先に書いたデータ後に書いたデータで上書きされてしまうので、データが一部なくなったり、データが途中で上書きされたりするリスクがあります。