Merge lp:~openerp-dev/openobject-server/6.0-opw-576744-rha into lp:openobject-server/6.0

[Rifakat Husen (OpenERP)]

Hello,

It doesn't let any user to login when MRP scheduler is running through cron job(ir.cron).
If user's row is currently aquire by scheduler then login() will not go through and prevents
updating the last login date, it's simpler to try to get the lock and if that fails, we skip
the login date update for once, that's no big deal.

It's a backport of server r4049, <email address hidden>

Regards,
Rifakat Haradwala

[Olivier Dony (Odoo) (odo-openerp)]

Looks good to me, but as this does not seem to fix the problem for the customer, I suggest we avoid the risk of merging it until we find the proper fix. Marking as rejected to avoid clustering the lists on Launchpad, feel free to reset the status if we later need it.
Thanks,

[lp:~openerp-dev/openobject-server/6.0-opw-576744-rha]

3634. By Olivier Dony (Odoo) on 2012-08-22

[FIX] res_users: improve behavior when user record is locked during login

Avoid logging an ugly and frightening traceback,
plus properly rollback the failed transaction before
continuing.

=== modified file 'bin/addons/base/res/res_user.py'
--- bin/addons/base/res/res_user.py	2011-05-09 10:24:54 +0000
+++ bin/addons/base/res/res_user.py	2012-08-22 15:41:20 +0000
@@ -440,16 +440,37 @@
             return False
         cr = pooler.get_db(db).cursor()
         try:
+            # autocommit: our single request will be performed atomically.
+            # (In this way, there is no opportunity to have two transactions
+            # interleaving their cr.execute()..cr.commit() calls and have one
+            # of them rolled back due to a concurrent access.)
+            # We effectively unconditionally write the res_users line.
+            cr.autocommit(True)
+            # Even w/ autocommit there's a chance the user row will be locked,
+            # in which case we can't delay the login just for the purpose of
+            # update the last login date - hence we use FOR UPDATE NOWAIT to
+            # try to get the lock - fail-fast
+            cr.execute("""SELECT id from res_users
+                          WHERE login=%s AND password=%s
+                                AND active FOR UPDATE NOWAIT""",
+                       (tools.ustr(login), tools.ustr(password)), log_exceptions=False)
             cr.execute('UPDATE res_users SET date=now() WHERE login=%s AND password=%s AND active RETURNING id',
                     (tools.ustr(login), tools.ustr(password)))
+        except Exception:
+            # Failing to acquire the lock on the res_users row probably means
+            # another request is holding it - no big deal, we skip the update
+            # for this time, and let the user login anyway.
+            cr.rollback()
+            cr.execute("""SELECT id from res_users
+                          WHERE login=%s AND password=%s
+                                AND active""",
+                       (tools.ustr(login), tools.ustr(password)))
+        finally:
             res = cr.fetchone()
-            cr.commit()
+            cr.close()
             if res:
                 return res[0]
-            else:
-                return False
-        finally:
-            cr.close()
+        return False
 
     def check_super(self, passwd):
         if passwd == tools.config['admin_passwd']: