Comment 10 for bug 992525

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