Tryton - Issues

 

Issue2906

Title no login possible while production requests are generated
Priority feature Status resolved
Superseder Nosy List albertca, ced, nicoe, ohuisman, rmu, vincent, yangoon
Type behavior Components trytond
Assigned To nicoe Keywords
Reviews

Created on 2012-11-28.17:27:46 by rmu, last changed by nicoe.

Messages
msg12792 (view) Author: [hidden] (nicoe) (Tryton committer) (Tryton translator) Date: 2013-03-23.19:20:53
Fix with changeset e7f5a027d901
msg12410 (view) Author: [hidden] (nicoe) (Tryton committer) (Tryton translator) Date: 2013-01-31.17:11:57
I updated the patch.
msg12282 (view) Author: [hidden] (albertca) (Tryton committer) (Tryton translator) Date: 2013-01-13.14:27:44
Regarding the "giant central point that res_user table is" may be alleviated by 
upcoming foreign key improvements in PostgreSQL which will probably be available 
in next (9.3) release:

http://www.postgresql.org/message-id/20130110210040.GB4110@alvh.no-ip.org
msg12240 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2012-12-27.14:10:15
I think there are two subjects on this issue:

- the login process: I think it is clear that it must be moved out of res_user
table (login_try, password, salt)

- the giant central point that res_user table is: we must decide if it is good
or not.
   - pros:
       - integrity

   - cons:
       - create a soft lock on res_user table for every INSERT/UPDATE
       - generate a lot of write if deleting user
       - not often used in the code
msg12239 (view) Author: [hidden] (albertca) (Tryton committer) (Tryton translator) Date: 2012-12-25.23:07:37
I think the right solution is to avoid the lock on res_user on login. This can be 
achieved by moving the login_try field to a new table. Then locks would happen 
between two logins but never with another transaction doing anything else.
msg12237 (view) Author: [hidden] (nicoe) (Tryton committer) (Tryton translator) Date: 2012-12-25.11:20:04
>> On 24/12/12 13:38 +0100, Nicolas Évrard wrote:
>> > We noticed that the foreign key constraint on create_uid and write_uid
>> > were the origin of the lock.
>>
>> I think we should still debate if dropping foreign key is the best
>> solution. After all we use relational database for this purpose.
>
>+1
>
>Shouldn't it only be write_uid, which is updated?

No because when you create a new record you also need to lock the
res.user table.
msg12235 (view) Author: [hidden] (yangoon) (Tryton translator) Date: 2012-12-24.16:15:16
> On 24/12/12 13:38 +0100, Nicolas Évrard wrote:
> > We noticed that the foreign key constraint on create_uid and write_uid
> > were the origin of the lock.
> 
> I think we should still debate if dropping foreign key is the best
> solution. After all we use relational database for this purpose.

+1

Shouldn't it only be write_uid, which is updated?

Highest priority for me should be to avoid long transactions. 
Next priority to outsource time critical elements from the transaction.

Dropping those foreign keys is against the concept of the database layout and is
a workaround, not a solution.
msg12234 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2012-12-24.13:41:39
On 24/12/12 13:38 +0100, Nicolas Évrard wrote:
> We noticed that the foreign key constraint on create_uid and write_uid
> were the origin of the lock.

I think we should still debate if dropping foreign key is the best
solution. After all we use relational database for this purpose.
msg12233 (view) Author: [hidden] (nicoe) (Tryton committer) (Tryton translator) Date: 2012-12-24.13:38:12
We noticed that the foreign key constraint on create_uid and write_uid
were the origin of the lock.

review625002 fixes this
msg12054 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2012-11-28.20:34:31
login_try should be stored in an other table to avoid login lock when a long
process has taken a lock on res_user.
msg12048 (view) Author: [hidden] (rmu) Date: 2012-11-28.19:31:14
this line blocks

http://hg.tryton.org/trytond/file/611614326a87/trytond/res/user.py#l459
msg12046 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2012-11-28.18:31:52
I guess it is because this line [1] generates a lock on the res_user
table. And as login need to read also this table [2], it is blocked
until generate_requests commit.

[1]
http://hg.tryton.org/modules/stock_supply_production/file/245850ce1814/production.py#l43
[2]
http://hg.tryton.org/trytond/file/611614326a87/trytond/res/user.py#l433
msg12045 (view) Author: [hidden] (rmu) Date: 2012-11-28.18:12:03
Some additional info: I try to login with the same user that is running the 
wizard. If I login before starting the wizard, I can use the second client, 
everything seems to work normally. This is on latest tip of version 2.6
msg12044 (view) Author: [hidden] (rmu) Date: 2012-11-28.18:04:40
I mean a separate client. 

The client that started the wizard is blocked (displays the "spinning wheel") and 
left undisturbed.
msg12043 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2012-11-28.17:35:55
Do you mean from the same client that started the wizard?
msg12042 (view) Author: [hidden] (rmu) Date: 2012-11-28.17:27:45
No login from tryton client is possible while the server generates production 
requests. Sessions that are already open seem to work fine.

output from tryton -v -d -l DEBUG:

INFO:tryton.rpc:common.server.version(None, None)
DEBUG:tryton.rpc:'2.6.2'
INFO:tryton.rpc:common.db.login(admin, xxxxxxxxxx)

Perhaps login-processing needs it's own thread/db-connection?
History
Date User Action Args
2013-03-23 19:20:54nicoesetstatus: chatting -> resolved
messages: + msg12792
2013-02-14 16:09:41ohuismansetnosy: + vincent
2013-01-31 17:11:57nicoesetmessages: + msg12410
2013-01-13 14:27:44albertcasetmessages: + msg12282
2013-01-07 14:03:48ohuismansetnosy: + ohuisman
2012-12-27 14:10:17cedsetstatus: testing -> chatting
messages: + msg12240
2012-12-25 23:07:38albertcasetnosy: + albertca
messages: + msg12239
2012-12-25 11:20:05nicoesetmessages: + msg12237
2012-12-24 16:15:17yangoonsetnosy: + yangoon
messages: + msg12235
2012-12-24 13:41:39cedsetmessages: + msg12234

Showing 10 items. Show all history (warning: this could be VERY long)