C# pool de conexões

No ADO.NET 2.0 tem.

Dá uma olhada nesse artigo

http://www.linhadecodigo.com.br/Artigo.aspx?id=1254&pag=2

O pool de conexões é automático no C# e totalmente transparente para o programador. Já é parte da API padrão.

ViniGodoy:

O pool de conexões é automático no C# e totalmente transparente para o programador. Já é parte da API padrão.

Na “connectionString”, pelo que pesquisei até agora, tem um atributo denominado “pooling”, que pode ser setado com um valor booleano. Quer dizer então que o valor default deste atributo é true?

Outra coisa:

O que acontece se eu fizer algo do tipo

lock(myConnection){}

numa aplicação asp.net? é preciso fazer isso? Isso traz algum tipo de problema?

No java seria o equivalente a fazer:

synchronized (myConnection) { }

E não precisa fazer.

Sim.

ViniGodoy:

No java seria o equivalente a fazer:

synchronized (myConnection) { }

E não precisa fazer.

Aproveitando pra fugir um pouco do assunto do tópico, como eu faço pra descobrir qual a maneira utilizada para implementar estas instruções de exclusão mútua?
Por exemplo, qdo duas threads chegam num bloco sychronized no mesmo objeto, o que acontece debaixo dos panos? A primeira entra e a outra fica em espera ocupada?
Tem um wait notify embutido que a gente não vê?

Sim.

E o que acontece se no finally eu der um close na conexão?

Ela volta automaticamente para o pool. A conexão só fechada de verdade quando fica muito tempo ociosa. É uma boa prática colocar o close num Finally ou criar a conexão dentro de um bloco using.

Dê uma lida: http://msdn.microsoft.com/en-us/library/ms173179.aspx

O lock equivale ao bloco synchronized. Para fazer o comportamento do wait e notify você precisa de Wait Handles.

Dê uma lida: http://msdn.microsoft.com/en-us/library/ms173179.aspx

O lock equivale ao bloco synchronized. Para fazer o comportamento do wait e notify você precisa de Wait Handles.

Então, mas como o synchronized é implementado?
Quando duas threads tentam acessar o mesmo objeto, a primeira entra e a outra espera. Mas esta espera é implementada de que maneira? A thread que espera fica checando o objeto eternamente até descobrir que o mesmo já foi liberado? Ou ela dorme e espera que a thread que entrou no bloco synchornized termine e envie um sinal para ela avisando que o lock foi liberado? Aliás, onde é que se acha detalhes desse tipo sobre o java?

Você pode obter informações sobre isso em livros de sistema operacional, na parte sobre exclusão mútua e região crítica.

Mas basicamente, existe uma fila de espera em todo trecho sincronizado. Quando alguma thread está lá dentro, o SO suspende a execução de novas threads e as coloca nessa fila. Assim que a thread sai, a primeira da fila é despertada e colocada para processar.

Então, realmente é como se houvesse um “wait” e “notify” implícitos (embora a execução desses comandos na realidade não ocorra).

ViniGodoy:

Você pode obter informações sobre isso em livros de sistema operacional, na parte sobre exclusão mútua e região crítica.

Mas basicamente, existe uma fila de espera em todo trecho sincronizado. Quando alguma thread está lá dentro, o SO suspende a execução de novas threads e as coloca nessa fila. Assim que a thread sai, a primeira da fila é despertada e colocada para processar.

Então, realmente é como se houvesse um “wait” e “notify” implícitos (embora a execução desses comandos na realidade não ocorra).

Li em algum lugar que o compilador do C# traduz o “lock” para:

Monitor.Enter(obj);
try{
 //região crítica
}
finally{
 Monitor.Exit(obj);
}

Então é possível que o javac na verdade traduza o synchronized para wait notify, não?

Se for será um bem especial, o “notify” que é dado quando sai do bloco synchronized não acordará qualquer wait explicitamente declarado.

Ele precisaria acordar todas as threads que ficaram esperando no synchronized…não? Pra elas ficarem sabendo que já podem entrar na região crítica…

Sim, mas ele tem um monitor próprio para as threads que dormiram pq o synchronized estava ocupado e outro monitor para quando elas dormiram com wait(). Assim o notify e o notifyAll() só atuaram nos waits(), enquanto sair do bloco sincronizado só atuará nas threads que dormiram na entrada do bloco.

Sim, mas ele tem um monitor próprio para as threads que dormiram pq o synchronized estava ocupado e outro monitor para quando elas dormiram com wait(). Assim o notify e o notifyAll() só atuaram nos waits(), enquanto sair do bloco sincronizado só atuará nas threads que dormiram na entrada do bloco.

É verdade…então cada objeto em java deve ter dois monitores. Um para ser usado pelo bloco synchronized, e outro para ser usado pelos wait e notify. E no fim das contas, a lógica usada para garantir a exclusão mútua é a mesma. Certo?

Acredito que sim.