openerp-india team mailing list archive

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

On 06/18/2012 03:20 PM, Marcos Mendez wrote:
> Basically, ten users trying to create a partner at the same time will
> fail - not all will work. I have provided the instructions on how to
> reproduce the error with JMeter. There are many errors in the log.
> 
> Please revisit this. I would hope that OpenERP can handle more than 5-8
> concurrent users doing reads and writes.

It seems your test is heavily biased. Unless I missed something, you are:
- simulating concurrent users that are all using the same login
- making the virtual users login before each request

The login call that is performed before each query is not only unnecessary but
will also cause an update to the user record in the database (to change the
last login time). And because all users are sharing the same login, this can
cause concurrent transactions to be invalidated due to potential conflicts on
the shared user record.

Please take these two factors out of the equation and see if you can reproduce
the problem.

It is valid to perform batch transactions using a unique login, e.g. for web
services integration, but if you do that in production you'll want to pay
attention to the following:
- No need to call login() every time, it's only used to get the user id (and
update the last login time, which you don't care about in this context)
- You *have to* implement a transaction queue, and implement appropriate error
handling! Things could go wrong anywhere in the flow: network, hardware, disk
space, database server, openerp server -> you *must* handle the various cases
appropriately, or you're asking for trouble in the future. In most cases the
solution will be to requeue the request, and this will work as well for the
error we're discussing here, if it ever happens.

PS: bug 1013223 does seem to be a duplicate of this bug

-- 
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