summaryrefslogtreecommitdiff
path: root/addons/web_graph/static/lib/dhtmlxGraph/codebase/thirdparty
diff options
context:
space:
mode:
authorXavier Morel <xmo@openerp.com>2012-01-25 12:58:23 +0100
committerXavier Morel <xmo@openerp.com>2012-01-25 12:58:23 +0100
commit3049760fe603c6e6e39fb989cb19572609e0fc85 (patch)
tree9e9c0b684cf7b6022ad429eda07659b88420fb9d /addons/web_graph/static/lib/dhtmlxGraph/codebase/thirdparty
parentd181a5e7acd2e3a50023d719474d239f5d0bd8c8 (diff)
[FIX] race condition in ir.ui.menu leading to incomplete menus in web client
See bug, issue occurs with variable frequency when changing between simple and extended views in a user account (non-administrator at least): saving the user account leads to a clearing of the menu cache, this is followed by two search/read in parallel (one to get the full menu listing and one to get the list of applications for the home page), which leads to ir_ui_menu.search (thus ir_ui_menu._filter_visible_menus) being called concurrently, and this apparently somehow wrecks havoc on some browse_record's caches yielding to incoherent behaviors (menus which do have children in db not having children in the browse_record, and thus being pruned from the list of menus). Putting a big lock around 1. clear_cache (just in case) and 2. _filter_visible_menu (to make cache-filling essentially atomic) seems to solve the issue or at least make it disappear, ideally more time should be spent understanding what breaks in browse_record. A reentrant lock is needed as _filter_visible_menu may recurse when accessing e.g. a menu's child_id (which yield a search([parent_id=menu.id]) and thus a _filter_visible_menu) lp bug: https://launchpad.net/bugs/920332 fixed bzr revid: xmo@openerp.com-20120125115823-rpu03zdv14t11lp3
Diffstat (limited to 'addons/web_graph/static/lib/dhtmlxGraph/codebase/thirdparty')
0 files changed, 0 insertions, 0 deletions