openerp-india team mailing list archive

["Olivier Dony \(OpenERP\)" <992525@xxxxxxxxxxxxxxxxxx>]

This error is only supposed to happen when two transactions read *then* write data at the same time in the database, in a manner that may have produced different results if they were executed one after the other instead.
That should not happen frequently even when many users are working on the system at the same time, unless the users are all modifying the same data exactly at the same time.

Now, there are a few things that might cause this issue to happen too frequently, such as:
- two persons sharing the same login
- PostgreSQL 9.1 used in combination with an old psycopg2 Python library version (older than 2.4.3)

You can find out the psycopg2 version with this command on the OpenERP server machine:
      $ python -c 'import psycopg2;print psycopg2.__version__'
       2.4.3 (dt dec mx ext pq3)

Older Pyscopg2 versions did not fully support the transaction isolation
mechanisms of PostgreSQL 9.1, and might cause this low-level protection
to trigger too often.

In other cases, the trigger of this error is a protection mechanism that ensures proper data integrity, and is essential for the safety of the transactions. It is likely it did not happen as often with OpenERP 6.0, and the reason is that the protection mechanism used in OpenERP 6.0 was not as efficient, and may have missed certain kind of dangerous concurrent updates.
OpenERP 6.1 is fully using the Snapshot Serialization Isolation mechanism of PostgreSQL, an industry-standard solution for maintaining transaction integrity [1].

As discussed, we can further improve the user experience by adding an
auto-retry mechanism in the transaction handling code, but the frequency
of such errors is supposed to be quite low under normal circumstances.

[1] http://en.wikipedia.org/wiki/Snapshot_isolation

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/992525

Title:
  TransactionRollbackError due to concurrent update could be better
  handled

Status in OpenERP Server:
  Confirmed

Bug description:
  While using openerp, psycopg2 raises TransactionRollbackError quite
  often even on small database.

  This does not seem to be easily reproduceable as it seems to be a
  conflict between two thread accessing the same table. Nevertheless, I
  provided a quick video reproducing this while installing "base_crypt"
  on my computer.

  This occurs mostly at module installation. And can completely mess up
  the module installation by giving empty wizard windows of instance.

  I guess it could also occurs in other situations (in multi-user
  context), where the bug would be quite difficult to reproduce and with
  unforeseeable consequences ;)

  I've spotted an other bug that is due to this it seems:
  https://bugs.launchpad.net/bugs/956715

  In my case (single user), it seem to hit more often on fast computers.
  To make a probable better guess, it seems to hurt more often whenever
  using a local connection between the browser and the server. It could
  be about the web module trying to update the res_users session info
  and may collide with normal operation.

  On my computer, from a new database, installing the 'base_crypt' will trigger the exception.
  When using a distant connection, the bug won't show up.

  Please check the video I've posted with the bug report if you want to
  have more detail on the procedure I used. Sorry for the bad sound
  recording. Note that the video will show you the bug occuring on my
  computer and NOT occuring on a distant computer.

  I'm providing a merge proposal along with this patch which solves the
  issue for me, but need a patient review.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/992525/+subscriptions