Tiago, eu tava pensando em algo mais simples ... tipo a ideia que o Renato acabou de postar.
[...]'s Marcio ======================================== ########### Campanha Ajude o Marcio! ########### http://sosmarcio.blogspot.com.br/ http://www.vakinha.com.br/VaquinhaP.aspx?e=195793 ======================================== Em 23 de setembro de 2013 19:05, Marcio - Google <[email protected]>escreveu: > R > enato++++ > > Era mais ou menos isso que tava pensando mesmo. > Mas como faço isso usando o DBI. Não consegui. > > > > [...]'s > > Marcio > > ======================================== > ########### Campanha Ajude o Marcio! ########### > http://sosmarcio.blogspot.com.br/ > http://www.vakinha.com.br/VaquinhaP.aspx?e=195793 > ======================================== > > > Em 23 de setembro de 2013 17:33, Renato Santos > <[email protected]>escreveu: > > explicando melhor, >> >> já que você não parece ter ninguem pra controlar de verdade quantos >> registros tem para ser processados, >> voce pode fazer um >> >> BEGIN; >> SELECT xxx FROM table WHERE not_processed LIMIT 1 FOR UPDATE ; >> <processa> >> UPDATE >> >> COMMIT; >> >> como só tem um 'limit 1' você teria q rodar isso várias vezes. >> >> vocẽ tambem pode aumentar o número, só que ai se você colocar 100, e só >> tiver 40 registros, o segundo e os demais processos não vão pegar ninguem. >> >> >> >> 2013/9/23 Renato Santos <[email protected]> >> >>> Como é mysql, só posso dizer: >>> >>> http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html >>> boa sorte! >>> >>> >>> >>> 2013/9/23 Marcio - Google <[email protected]> >>> >>>> Salve Mongers! >>>> >>>> Tenho uma tabela em MySql com algumas centenas de registros. >>>> >>>> Em alguns momentos tenho que "processar" esses registros da forma mais >>>> rápida possível. >>>> >>>> O tempo de processamento de cada registro é de aproximadamente 4-5 >>>> segundos, tempo esse alheio ao meu controle ou a minha vontade. >>>> >>>> Para agilizar, rodo várias vezes o mesmo app, e cada vez que ele sobe >>>> pega um lote de registros. Para impedir que a próxima cópia do app a subir >>>> pegue os mesmos registros, criei uma coluna a mais, e quando o app sobe ele >>>> verifica se a coluna tá vazia, se tiver ele grava o PID dele. >>>> >>>> Está funcionando mais ou menos, exceto pelo fato que não gostei da >>>> forma que ficou e de um efeito colateral. As vezes uma das cópias do app dá >>>> algum erro e cai, só que os registros do lote dele ficam lá com o PID >>>> gravado na coluna, então as outras cópias não mexem mais com esses >>>> registros e eles ficam indefinidamente pendentes. >>>> >>>> Alguma dica de como fazer algo "mais elegante" e "seguro"? >>>> >>>> Para adiantar: >>>> 1. Tem que ser MySql. Posso mexer na tabela a vontade. >>>> 2. O processamento não tem como ser mexido. >>>> >>>> >>>> [...]'s >>>> >>>> Marcio >>>> >>>> ======================================== >>>> ########### Campanha Ajude o Marcio! ########### >>>> http://sosmarcio.blogspot.com.br/ >>>> http://www.vakinha.com.br/VaquinhaP.aspx?e=195793 >>>> ======================================== >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: [email protected] >>>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >>>> =end disclaimer >>>> >>>> >>> >>> >>> -- >>> Saravá, >>> Renato CRON >>> http://www.renatocron.com/blog/ >>> @renato_cron <http://twitter.com/#!/renato_cron> >>> >> >> >> >> -- >> Saravá, >> Renato CRON >> http://www.renatocron.com/blog/ >> @renato_cron <http://twitter.com/#!/renato_cron> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: [email protected] >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> =end disclaimer >> >> >
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
