[SP-pm] Bloqueando registros para processamento

[Renato Santos]

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 <marciorp at gmail.com>

> 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: SaoPaulo-pm at pm.org
>  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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130923/8503b1cf/attachment.html>