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