[FIX] ir.attachment: less non-transactional side-effects during deletion
authorOlivier Dony <odo@openerp.com>
Wed, 3 Sep 2014 16:39:25 +0000 (18:39 +0200)
committerOlivier Dony <odo@openerp.com>
Mon, 8 Sep 2014 14:52:42 +0000 (16:52 +0200)
commita03dfefda9b4ea3554b9dc23ca9ebeb706b15ff1
tree86e598dc9859c991c58182bc5950ddc8b8f6b087
parent46784659f9c9b25cfb243e7ca5094df738fdd880
[FIX] ir.attachment: less non-transactional side-effects during deletion

When deleting filesystem-backed attachements, the
deletion on the file-system is not transactional.
In the event of a transaction rollback, the file
deletion would not be rolled back, which is a
dangerous side-effect.

This can happen for example when several transactions
try to delete the same file(s) at the same time.
The duplicate deletions might be detected by the
database (being concurrent update errors), and rolled
back at the point of the DELETE query, to be retried.
If the files have already been deleted in the file
system it before the rollback, it leaves the system
in an inconsistent state, at least temporarily.

One case where we have seen it is when web bundles
are loaded by many web users at the same time, right
after being updated (and thus invalidated).
As they are currently cached as ir.attachment records,
this often causes a corruption of the cache.
openerp/addons/base/ir/ir_attachment.py