Agreed. I will modify the test bias and send updates. We will also have automated systems, so this was trying to simulate that also. We can do the login once. I just expect OpenERP to handle a normal load. So will change the test to remove that bias.

Thanks

On Jun 18, 2012, at 9:59 AM, Olivier Dony (OpenERP) wrote:

> 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 subscribed to a
> duplicate bug report (1013223).
> 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