BLOQUEAR UM MODULO DO SISTEMA NA REDE
Olá Pessoal
Tenho um servidor e dois pcsCientes ligados a ele, executável e banco estão no servidor.
aciono pc1 em entro num determinada Rotina do form1 e fica lá processando uma serie de cálculos, loops, etc
como faço para o segundo pc2 não consiga entrar no mesma rotina que o Pc1 entrou por primeiro até que o Pc1 finalise seu processamento e libere a rotina1 para outro pc da rede possa entrar.
Eu imagino que poderia ser acionado uma Variável = true na hora que entra no módulo, a hora que terminar fica Variavel = false
Outro pc só pode entrar no mesmo local se variável = False
mas como declaro uma Variável para toda a rede?
Até imagino um timer de 1 em 1segundo
o PC2 vendo se a rotina já está desbloqueada para poder entrar.
Grato
Tenho um servidor e dois pcsCientes ligados a ele, executável e banco estão no servidor.
aciono pc1 em entro num determinada Rotina do form1 e fica lá processando uma serie de cálculos, loops, etc
como faço para o segundo pc2 não consiga entrar no mesma rotina que o Pc1 entrou por primeiro até que o Pc1 finalise seu processamento e libere a rotina1 para outro pc da rede possa entrar.
Eu imagino que poderia ser acionado uma Variável = true na hora que entra no módulo, a hora que terminar fica Variavel = false
Outro pc só pode entrar no mesmo local se variável = False
mas como declaro uma Variável para toda a rede?
Até imagino um timer de 1 em 1segundo
o PC2 vendo se a rotina já está desbloqueada para poder entrar.
Grato
Nem uma dica?
Vendo o cenário rapidamente acho que daria pra resolver de dois modos assim:
1º O PC que acionar o processo cria um arquivo ou uma flag dentro de um arquivo ja esistente no servidor, o PC2 se tentar executar ele verifica a flag e se estiver la marcada não executa e avisa o usuário que ja esta executando no PCx;
2º Fazendo o mesmo processo acima mais com uma flag dentro do banco de dados.
Desvantagem nisso:
Se por acaso o processo travar, a rede cair, ou o usuário fechar o sistema brutalmente, a flag não estará limpa e ficara travada ate que voce destrave ela manualmente.
1º O PC que acionar o processo cria um arquivo ou uma flag dentro de um arquivo ja esistente no servidor, o PC2 se tentar executar ele verifica a flag e se estiver la marcada não executa e avisa o usuário que ja esta executando no PCx;
2º Fazendo o mesmo processo acima mais com uma flag dentro do banco de dados.
Desvantagem nisso:
Se por acaso o processo travar, a rede cair, ou o usuário fechar o sistema brutalmente, a flag não estará limpa e ficara travada ate que voce destrave ela manualmente.
Thread safety é um conceito existente no contexto de programas
multi-threads onde um trecho de código é thread-safe se :
ele funcionar corretamente durante execução simultânea por vários threads.
Se o código não for thread-safe e estiver rodando em um ambiente multi-threads os resultados obtidos podem ser inesperados ou incorretos pois uma thread pode desfazer o que a outra thread já realizou. Esse é o problema clássico da atualização do contador em uma aplicação multi-thread.
Para resolver este problema podemos usar a instrução lock() que vai bloquear os recursos até que a thread que o esta usando acabe de processá-lo.
O lock funciona assim : Quando duas threads simultâneas contêm um lock() ou bloqueio, uma thread espera, até que o bloqueio seja liberado. Neste caso, somente uma thread terá acesso ao recurso por vez e dessa forma torná-lo thread-safe.
http://www.macoratti.net/10/09/c_thd1.htm
multi-threads onde um trecho de código é thread-safe se :
ele funcionar corretamente durante execução simultânea por vários threads.
Se o código não for thread-safe e estiver rodando em um ambiente multi-threads os resultados obtidos podem ser inesperados ou incorretos pois uma thread pode desfazer o que a outra thread já realizou. Esse é o problema clássico da atualização do contador em uma aplicação multi-thread.
Para resolver este problema podemos usar a instrução lock() que vai bloquear os recursos até que a thread que o esta usando acabe de processá-lo.
O lock funciona assim : Quando duas threads simultâneas contêm um lock() ou bloqueio, uma thread espera, até que o bloqueio seja liberado. Neste caso, somente uma thread terá acesso ao recurso por vez e dessa forma torná-lo thread-safe.
http://www.macoratti.net/10/09/c_thd1.htm
Jba, é bem isso que acontece
uma thread pode desfazer o que a outra thread já realizou
Está acontecendo quando mais de uma maquina vai imprimir boleto de cobrança
por ex. o sistema diz que o próximo numero do boleto é 12345
se outro usuário abrir tb irá dizer que o próximo boleto é 12345
se um executar e depois o outro sem problema, ele fara um boleto 12345 e o outro 12346 (ele revisa se o boleto já existe e soma 1)
O problema se eles executarem quase 100% juntos, o sistema acaba criando dois boletos iguais 12345
Eu até criei um flag no servidor como MARCELOKROL falou. mas pensei o mesmo e se der algum pau no meio do caminho, a flag está acionada para não fazer o boleto, aà tem que desmarca-la manualmente...explicar isso para o cliente complica.
Vou dar uma olhada de tal de Lock e ver como funciona
valeu, depois retorno para dizer como ficou.
uma thread pode desfazer o que a outra thread já realizou
Está acontecendo quando mais de uma maquina vai imprimir boleto de cobrança
por ex. o sistema diz que o próximo numero do boleto é 12345
se outro usuário abrir tb irá dizer que o próximo boleto é 12345
se um executar e depois o outro sem problema, ele fara um boleto 12345 e o outro 12346 (ele revisa se o boleto já existe e soma 1)
O problema se eles executarem quase 100% juntos, o sistema acaba criando dois boletos iguais 12345
Eu até criei um flag no servidor como MARCELOKROL falou. mas pensei o mesmo e se der algum pau no meio do caminho, a flag está acionada para não fazer o boleto, aà tem que desmarca-la manualmente...explicar isso para o cliente complica.
Vou dar uma olhada de tal de Lock e ver como funciona
valeu, depois retorno para dizer como ficou.
Essa questão dos numeros de boletos iguais, vc resolve desde que esses campos sejam chave primaria, nesse caso quando o
usuario segundo tentar gerar um boleto com o mesmo numero, um erro de duplicidade acontece gerado pelo banco de dados, então vc gera um loop, acrescentando
+1, até o erro cessar, isso é seguro e faço a mais de 10 anos em sistemas multi usuarios.
usuario segundo tentar gerar um boleto com o mesmo numero, um erro de duplicidade acontece gerado pelo banco de dados, então vc gera um loop, acrescentando
+1, até o erro cessar, isso é seguro e faço a mais de 10 anos em sistemas multi usuarios.
eu já tenho uma chave primaria que no momento não serve para nada, mas vou muda-la para o numero do boleto e testar, parece interessante.
estava estudando o Lock, mas começou a dor um nó na cabeça
Valeu
estava estudando o Lock, mas começou a dor um nó na cabeça
Valeu
Citação::
Essa questão dos numeros de boletos iguais, vc resolve desde que esses campos sejam chave primaria, nesse caso quando o
usuario segundo tentar gerar um boleto com o mesmo numero, um erro de duplicidade acontece gerado pelo banco de dados, então vc gera um loop, acrescentando
+1, até o erro cessar, isso é seguro e faço a mais de 10 anos em sistemas multi usuarios.
agora complicou.
vários registros possui o campo numero do Boleto em branco e recebera um numero só na hora de imprimir
na verdade os boletos são pré configurados e ficam sem numero até a impressão
tem como eu colocar chave primária no campo numeroBoleto e o SQL server não considerar campos vazios na chave?
tenho campo numeroboleto vazios e não nulos
se não der de criar a chave por causa dos campos em branco, terei que criar uma segunda tabela só com números dos boletos já criados, sem os boletos em branco
Prezado,
A resposta de MARCELOKROL me parece a mais adequada ao seu caso (assim como ele também olhei rapidamente e considerando que os campos que definem a unicidade do boleto podem estar em branco).
A resposta de MARCELOKROL me parece a mais adequada ao seu caso (assim como ele também olhei rapidamente e considerando que os campos que definem a unicidade do boleto podem estar em branco).
Achei uma alternativa é quase uma POG tomando como base a solução do NILSONTRES
Coloquei mais uma coluna Chamada Cb1DocumentoTemp que será chave, ao configurar o Boleto o campo Cb1Documento será vazio mas o Cb1DocumentoTemp terá um numero qualquer no caso o próprio numero do registro com zeros na frente para ficar um valor menor que os numero dos boletos.
Quando gerar o Boleto ele irá salvar o Numero no Cb1Documento e no Cb1DocumentoTemp como o Cb1DocumentoTemp é chave, dará erro se o numero já existir, aà é só tratar o erro somando +1 no Numero do boleto até conseguir salvar
Acho que é isso aÃ
Coloquei mais uma coluna Chamada Cb1DocumentoTemp que será chave, ao configurar o Boleto o campo Cb1Documento será vazio mas o Cb1DocumentoTemp terá um numero qualquer no caso o próprio numero do registro com zeros na frente para ficar um valor menor que os numero dos boletos.
Quando gerar o Boleto ele irá salvar o Numero no Cb1Documento e no Cb1DocumentoTemp como o Cb1DocumentoTemp é chave, dará erro se o numero já existir, aà é só tratar o erro somando +1 no Numero do boleto até conseguir salvar
Acho que é isso aÃ
Atenção: O conceito de thread não se aplica no caso de instâncias diferentes.
Ainda assim, o problema pode ser sanado se o conjunto de rotinas que hoje reside no executável for transformado em um serviço Windows.
A outra questão, relativa á numeração das boletas (ou boletos), também seria sanada com essa solução. Mas veja, caso não queira lançar mão de um Windows service, note a chave primária é sempre relativa ao registro, enquanto que essa numeração é relativa ao documento fiscal e pode até obedecer á critérios variantes, de acordo com a empresa. Assim, ao invés de enviar uma instrução SQL complete para a atualização de todos os dados, você pode manter a chave primária como autonumeração (identificando assim o registro) e implementar/usar um procedimento armazenado para a atualização efetiva dos dados, que [Ô]chame[Ô] esse número por meio de um gatilho ou função de usuário.
Ainda assim, o problema pode ser sanado se o conjunto de rotinas que hoje reside no executável for transformado em um serviço Windows.
A outra questão, relativa á numeração das boletas (ou boletos), também seria sanada com essa solução. Mas veja, caso não queira lançar mão de um Windows service, note a chave primária é sempre relativa ao registro, enquanto que essa numeração é relativa ao documento fiscal e pode até obedecer á critérios variantes, de acordo com a empresa. Assim, ao invés de enviar uma instrução SQL complete para a atualização de todos os dados, você pode manter a chave primária como autonumeração (identificando assim o registro) e implementar/usar um procedimento armazenado para a atualização efetiva dos dados, que [Ô]chame[Ô] esse número por meio de um gatilho ou função de usuário.
Tópico encerrado , respostas não são mais permitidas