Comment 11 for bug 992525

Hi,

Is there some code/example about how to make a user a manager of a group? I'm trying to automate the creation of users to do this test properly. I can create the user, but just assigning group_ids is not enough when creating the user.

For example:
# CREATE USER
data = {
#'groups_id': [9, 2, 8, 19, 23, 21, 13, 11, 17, 7, 12, 18, 20, 1, 22, 3],
'password': 'test',
'active': True,
'name': 'Test',
'login': 'test',
}

sock = xmlrpclib.ServerProxy('http://%s:8069/xmlrpc/object'%host)
id = sock.execute(dbname, uid, pwd, model, 'create', data)

On Jun 18, 2012, at 11:25 AM, Marcos Mendez wrote:

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