recently on trunk (around RC3), we had a new kind of errors that has been recognized by other partners too:
sometimes, when saveing a record, at least with the GTK client, we have a "concurrent access" warning.
The popup seems to come fro the write method in orm.py and especially from that code snippet:
if delta and self._log_access:
for i in range(0, len(ids), cr.IN_MAX):
sub_ids = ids[i:i+cr.IN_MAX]
cr.execute("select (now() - min(write_date)) <= '%s'::interval " \
"from %s where id in (%s)" %
(delta, self._table, ",".join(map(str, sub_ids))))
res = cr.fetchone()
if res and res[0]:
for field in vals:
if field in self._columns and self._columns[field]._classic_write:
raise except_orm(_('ConcurrencyException'),
_('This record was modified in the meanwhile'))
This is very hard to reproduce the bug, it really seems inconsistent.
We think this is due to now() - min(write_date)) <= '%s'::interval comparing very close numbers. I think that network latency or server temporary overhead might explain the bug.
Here in French the explanation I gave in the #openerp-fr irc channel on freenode:
13:11 rvalyi imaginez la situation suivante:
13:12 rvalyi instant t: le client lance un premier appel write et lance son propre chrono qui donnera le delta de temps d'édition au prochain appel
13:13 rvalyi or, à cause de la latence réseau ou d'éventuelle lenteur, le serveur tarde à écrire le recor et donc son write_date est sensiblement plus tard que l'instant t
13:14 rvalyi quelques secondes après, le client lance un second write à l'instant t + delta
13:15 rvalyi pour le client il s'est écoulé delta et c'est le param qu'il balance au serveur pour tester la concurrence (param rpc read_delta)
13:15 rvalyi or, le serveur est cette fois véloce et la latence réseau est faible
13:16 rvalyi du coup, le serveur, dit, dans ce code http://pastie.org/354575, que delta est supérieur à l'intervale now - write-date
13:16 rvalyi et une fausse concurrence est détectée, CQFD!!!!!!
13:16 rvalyi any thought?
I don't see any trivial fix that would also ensure true concurrent accessed are detected, but I hope this report helps.
Raphaël Valyi
OK, so after discussing this on irc, with Cedric Krier and Christophe Chauvet (Syleam), it appear that it's just on old problem popping up again:
http://
I guess this annoyance just reached a new level, because both for Christophe and me, the popup ARE QUITE frequent. Like w few times an hour. The more loaded the server is, the more popups there are. I think it's because the Python mutithreading is such a joke (giant lock implementation), that answering several users (or scheduled jobs) just slow down the server, making it more likely the client read_delta is not consistent with the real delta time seen by the server.
Fabien even took position to defend the current position (see previous link), but may be he had no idea back in 2007 how often it does occur now.
Tryton fixed the bug by creating an other hole, meaning they favor not detecting real true concurrent writes instead of having false positives, see their commit on the code I mentioned:
http://
Currently, the situation for ou customer is that popus occur so much often that: they are likely to say to their users: well if you see a popup, then just ignore it.
Meaning that the real result of such a choice is exactly the same as the concurrency hole in Tryton: users WILL MISS true positive concurrent writes. But instead of Tryton, in OpenERP you also fed up the usrs with the popups...
Instead, Cristophe and I think that we could dramatically improve the current test, at least by testing:
if both the concurrence is due to the SAME user and if the the concurrence condition is detected because OF A TINY TIME AMOUNT (like a half second), then we could IGNORE the concurrency warning. Indeed, in the worst case it will be the same users using several tabs in its client, but if he manage to save two different tabs within one second without remembering, he will deserve his popup at least.
Any thought?