diff options
| author | Xavier Morel <xmo@openerp.com> | 2012-01-25 12:58:23 +0100 |
|---|---|---|
| committer | Xavier Morel <xmo@openerp.com> | 2012-01-25 12:58:23 +0100 |
| commit | 3049760fe603c6e6e39fb989cb19572609e0fc85 (patch) | |
| tree | 9e9c0b684cf7b6022ad429eda07659b88420fb9d /addons/web_graph/static/lib/dhtmlxGraph/codebase/dhtmlxchart.js | |
| parent | d181a5e7acd2e3a50023d719474d239f5d0bd8c8 (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/dhtmlxchart.js')
0 files changed, 0 insertions, 0 deletions
