Synclock em WCF

Question

O Synclock funciona normalmente com WCF ou existe algum método melhor para a mesma finalidade?

---

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" (Martin Fowler)

Answer 1

Boas Leandro,

Sim, funciona. Mas tome cuidado porque esse tipo de sincronismo faz com que apenas uma única thread acesse aquela região protegida.

Mais detalhes: http://www.israelaece.com/post/WCF-Video-Sincronizacao.aspx

---

http://www.israelaece.com

Answer 2

Israel boa tarde,

estive pensando aqui com meus botões. Eu tenho 5 windows services (um pra cada módulo do meu sistema) que acessarão a mesma dll de regra de negócio e de dados (até pq os modulos se conversam internamente. A requisição do cliente é uma só, mas dentro da regra de negócio, um módulo pode precisar de dados que seriam de outro módulo por exemplo).
Como eu faço para ter uma unica instância da parte de dados?
Eu gostaria de controlar as transações, pois caso dois usuários solicitem a mesma coisa, eu só posso responder para o segundo após completar a requisição do primeiro (uma pode afetar diretamente o conteudo da outra). Pensei em dar um SyncLock nestes métodos, mas depois me toquei. Como são 5 serviços diferentes, e eles estarão referenciado a mesma DLL, eles abrirão 5 instâncias (uma para cada serviço) quando precisar acessar um método ou objeto, não? Dessa forma o Synclock não serviria pra nada.

Você entendeu minha dúvida? Posso ter confundido mais do que explicado tb.

Desde já, obrigado

---

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" (Martin Fowler)

Answer 3

Boas Leandro,

Se você tem 5 ou N serviços rodando em aplicações diferentes, como é o seu caso (5 Windows Services), mesmo que todos refereciem a mesma DLL, cada um terá a sua própria instância, ou seja, ela não será compartilhada. Cada serviço carregará a DLL para dentro do seu processo (EXE) e a utilizará. Qualquer mudança que faça, não refletirá noutro.

O SyncLock (lock) faz com que uma região do teu código seja protegido por múltiplas threads concorrentes. No seu caso, a concorrência será entre as várias requisições que chegam para um mesmo serviço que consome a DLL, se repetindo para os outros 4, mas lembre-se, cada um com sua respectiva "cópia" da DLL.

---

http://www.israelaece.com

Answer 4

Estou vendo seu video agora.
Um jeito de conseguir meu objetivo, é possuir um windows service para a regra de negócio. Utilizaria Instância Single para Sincronização Single também, e evitaria de um usuário tentar passar a frente de outro em momentos indevidos, certo? Ou entendi errado?

Se dois clients acessarem o mesmo método, o segundo é enfileirado. Se acessarem métodos diferentes da mesma DLL, eles são executados simultaneamente. É isso mesmo? Se for, acho que é assim que vou resolver meu problema

Mais uma vez, muito obrigado.

---

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" (Martin Fowler)

Answer 5

Boas Leandro,

Sim, é isso. Mas o que precisa se preocupar é com a concorrência. Talvez, dependendo do quantidade de acessos que possui, bloquear a classe toda pode ser ruim, já que podem haver outros processos que poderíamos executar em paralelo. Neste caso, o que pode fazer é refinir o bloqueio, utilizando técnicas de lock tradicionais, já fornecidas pelo .NET Framework, assim como o próprio SyncLock.

---

http://www.israelaece.com

Answer 6

Israel,

meu principal objetivo era controlar o banco de dados. Meu medo era dois usuários distintos executarem o mesmo comando no banco e isso gerar algum conflito. Conversando com o Victor aqui do forum por msn ontem a noite, ele me explicou que isso meu sistema ja faz hoje. As transactions do banco conseguem gerenciar isso.
Se eu entendi tudo certo, acredito não precisar do synclock por enquanto
mesmo assim muito obrigado!


att
Leandro

---

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" (Martin Fowler)