A Dimecres, 13 de gener de 2010, Ferdinand Gassauer va escriure:
> Am Mittwoch 13 Januar 2010 16:55:37 schrieb Albert Cervera i Areny:
> > A Dimecres, 13 de gener de 2010, Ferdinand Gassauer va escriure:
> > > Am Mittwoch 13 Januar 2010 15:41:49 schrieb Albert Cervera i Areny:
> > > > A Dimecres, 13 de gener de 2010, Cloves Almeida va escriure:
> > > > > One solution would be a select for update on picking row, which
> > > > > presumably would do the same as a locking table.
> > > >
> > > > You're right, we can either create a special table or use SELECT FOR
> > > > UPDATE on the same table.
> > >
> > > To my understanding "select for update" does not prohibit concurrent
> > > reads. if we want to make this method work - "select for update" has to
> > > be done for all "other" open stock moves for this product which must
> > > not be updated during the validation process of the current stock_move
> >
> > The idea I had in mind explicitly avoided blocking other selects. Only
> >  other processes trying to assign the stock move should be locked, and
> > all those will, of course, use SELECT FOR UPDATE.
> >
> > I will probably write a patch shortly and will probably use LOCK TABLE on
> > a special table just because it allows reusing some existing functions.
> 
> I hope you will only block processes which also want to assign the products
>  of the current picking - although this will matter only in installations
>  with many stock users.
> 

You're right, although it won't be an issue for most companies, I'll take a 
look and see what needs to be changed to use SELECT FOR UPDATE..

-- 
Albert Cervera i Areny
http://www.NaN-tic.com
Mòbil: +34 669 40 40 18

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community-leaders
Post to     : openerp-community-leaders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-community-leaders
More help   : https://help.launchpad.net/ListHelp

Reply via email to