4
나는 내가 영리하다고 생각했다. 그러나 최근의 발견에 비추어 볼 때 더 이상 확신 할 수 없습니다. 페이지 수명주기 동안 모든 데이터베이스 상호 작용이 가능합니다. 일부는 뒤로, 다른 일부는 밖으로 퍼집니다. 그래서 HttpContext.Items 사전에 SQL 연결의 인스턴스를 유지하는 객체를 만들었습니다. 모든 db 요청은이 연결을 사용하고 http 요청이 끝나면 연결을 적절하게 처리합니다. 우리는 연결이 열리는 몇 백 밀리 초를보고 있습니다. 그리고 무거운 http 캐싱으로 사용 가능한 연결이 부족한 것은 걱정할 필요가 없습니다.SqlConnection 및 풀은 kung-foo 또는 foo-bar를 열린 연결로 유지하고 있습니까?
요점은 새로운 연결 설정으로 인한 추가 왕복을 방지하는 것이 었습니다. 하지만 커넥션 풀링에 대한 지식을 찾았을 때 SqlConnection을 유지하는 것이 얼마나 유용한 지 알 수 없습니다. 아니면 그렇습니까?
시나리오 A는 시나리오 B와 성능면에서 동일합니까? 어느 것이 좋습니다? 시나리오 B는 성능이 향상되지 않으며 연결이 제대로 처리되지 않을 수있는 몇 가지 모서리 때문에 방해가 될 수 있습니다. 예제에서의 가짜를 용서하십시오. 나는 바코드로 그들을 어지럽히고 싶지 않습니다.
using (var connection = new SqlConnection(connectionString))
{
using (var command = new SqlCommand("...", connection))
{
... doing database stuff ...
}
}
... traversing the stack ...
using (var connection = new SqlConnection(connectionString))
{
using (var command = new SqlCommand("...", connection))
{
... doing database stuff ...
}
}
B
var connectionKeeper = new ConnectionKeeper();
// Add to the context items so it can be used anywhere
Context.Items.Add("Connection", connectionKeeper);
... traversing the stack ...
using (var command = new SqlCommand("...", connectionKeeper.Connection))
{
... doing database stuff
}
... traversing the stack ...
using (var command = new SqlCommand("...", connectionKeeper.Connection))
{
... doing database stuff
}
... traversing the stack ...
// The end of the request
sqlKeeper.Dispose();
동의 - SQL 서버는 (귀하의 저울에 맞게 조정할 수있는) inbuilt 연결 풀링 메커니즘을 가지고 있으므로 연결을 유지하는 것에 대해 걱정하지 마십시오. 단지 풀이 마술이되도록하십시오 –
그건 제가 최근 생각한 것입니다. 확인해 주셔서 감사합니다. – Levitikon
MSDN에서 ADO.NET 풀링 아티클에 대한 자세한 내용을 업데이트하고 싶습니다. 얼마나 자주이 점에 대해 논해야하는지 놀랍습니다. 수영장에서 일하게하십시오! – mafue