Tôi có ứng dụng khách .net được kết nối với cơ sở dữ liệu từ xa. Có an toàn để giữ một kết nối duy nhất mở trong suốt thời gian của khách hàng (giờ) không?là an toàn để giữ kết nối cơ sở dữ liệu mở trong thời gian dài
Câu trả lời có giữ được nếu tôi có nhiều (10 hoặc 100) ứng dụng đang chạy không?
Cảm ơn
Bạn không nên giữ các kết nối mở như thế này, nói chung. .NET có một hệ thống gộp kết nối ADO.NET thực hiện chính xác những gì bạn đang cố gắng làm và làm tốt hơn rất nhiều. ;-)
cập nhật: tôi là một 'thợ săn. đăng phản ứng. không áp dụng ở đây.
-Oisin
Chắc chắn. Bạn thực sự chỉ có vấn đề khi bạn giữ giao dịch mở trong một thời gian dài (ở mức cô lập nhất định).
Có giới hạn kết nối được cấp phép và kết nối thực hiện bộ nhớ trên máy chủ, vì vậy, càng ít, thì càng tốt.
Phụ thuộc vào cơ sở dữ liệu và những gì bạn đang làm với nó. Có một chi phí để mở và đóng bất kỳ kết nối cho hầu hết các phần. Ví dụ, nếu bạn đang sử dụng SQLCE trên thiết bị di động (SQL Server Compact Edition) thì đây thực sự là một cách tiếp cận được khuyến nghị để kết nối mở trên thiết bị vì chi phí mở và đóng nó không đáng để gặp rắc rối.
Ngược lại, nếu bạn đang làm việc với cơ sở dữ liệu nhiều người dùng, bạn sẽ muốn quản lý các kết nối đó cẩn thận hơn. Như đã đề cập, việc kết nối ADO.Net thực hiện một công việc khá tốt trong việc giúp bạn quản lý hiệu quả.
Tuyệt đối an toàn khi thực hiện việc này. Đây là cách các ứng dụng client-server hoạt động. Nếu bạn đang sử dụng một ứng dụng ba tầng, máy chủ ứng dụng sẽ giữ một nhóm các kết nối đang mở.
Khả năng mở rộng là một vấn đề hoặc ít nhất là sử dụng trong những ngày máy có ít bộ nhớ hơn so với bộ hiện đại. Với một ứng dụng hai tầng (client-server), mỗi khách hàng đã mở một kết nối và giữ nó mở. Điều này có nhiều tác dụng:
Memory đã được sử dụng cho mỗi kết nối, vì vậy số lượng lớn (tương đối) nhàn rỗi kết nối sẽ sử dụng lên máy bộ nhớ . Tuy nhiên, máy chủ 64 bit hiện đại có thể có hàng chục hoặc hàng trăm bộ nhớ GB, do đó, nó có thể hỗ trợ số lượng rất lớn các kết nối như vậy.
Nếu giao dịch bị để lại không được cam kết trên máy khách, khóa sẽ được mở để làm miễn là giao dịch được mở. Điều này dẫn đến một loạt các vấn đề khi ai đó có thể bắt đầu giao dịch, đi ăn trưa và quên rằng họ có để lại thứ gì đó mở. Điều này sẽ khóa bất kỳ hồ sơ nào được tham chiếu bởi giao dịch hàng giờ tại một thời điểm.
Giao dịch có thể dễ dàng bao gồm nhiều lần truy cập vào cơ sở dữ liệu , khó thực hiện hơn với một hồ bơi conneciton.
Kiến trúc tổng hợp, phổ biến trên kiến trúc 3 tầng có số lượng kết nối hữu hạn giữa máy chủ ứng dụng và cơ sở dữ liệu. Truy vấn chỉ đơn giản là sử dụng kết nối có sẵn tiếp theo và cập nhật được cam kết ngay lập tức. Điều này sử dụng ít tài nguyên hơn vì bạn chỉ có một số lượng kết nối hữu hạn mở, và (kết hợp với chiến lược optimistic concurrency) sẽ loại bỏ một số lượng lớn các vấn đề tương thích ứng dụng tiềm năng.
Để sử dụng long transactions (tức là các giao dịch bao gồm nhiều lệnh gọi đến cơ sở dữ liệu), một giao dịch phải hủy kết nối giao dịch khỏi kết nối. Đây là kiến trúc cơ bản của màn hình TP và có một số giao thức chuẩn như XA hoặc OLE Transactions để hỗ trợ điều này. Nếu loại giao dịch được quản lý bên ngoài này không khả dụng, ứng dụng phải tạo một compensating transaction để hoàn tác các thay đổi được thực hiện bởi giao dịch của ứng dụng. Loại kiến trúc này thường được sử dụng bởi workflow management systems.
Nó an toàn. Đó là khá nhiều những gì pooling không ... giữ cho các kết nối mở cho chiều dài của chương trình chạy và sử dụng nó cho các truy vấn khác nhau.
Nhưng bạn có thể muốn xem hết thời gian chờ kết nối cơ sở dữ liệu. Kết nối sẽ bị lỗi thời và bạn sẽ bắt đầu gặp phải các lỗi lạ. Đặt giá trị thời gian chờ trong cơ sở dữ liệu thành một giá trị rất lớn hoặc giữ kết nối với các truy vấn giả thường xuyên.
Khó khăn với kết nối lâu dài là bạn có thể không hoàn toàn chắc chắn rằng họ vẫn còn ở đó. Lỗi mạng, khởi động lại máy chủ hoặc tường lửa trạng thái quên một số trạng thái của nó có thể dẫn đến kết nối "cũ" có vẻ mở, nhưng sau đó đưa ra lỗi khi bạn cố gắng sử dụng nó.
Đề án tổng hợp kết nối thường giải quyết vấn đề này bằng cách thỉnh thoảng kiểm tra xem các kết nối trong hồ bơi có lành mạnh không, hoặc hết thời gian chờ sau khi kết nối không sử dụng bị ngắt.
Nói chung, trong một hệ thống phân tán, bạn cần mã hóa xung đột về các loại, giữ kết nối lâu dài mở làm cho việc này trở nên khó khăn hơn - nhưng nếu bạn vui vẻ làm điều đó, thật tuyệt.
Nó thực sự phụ thuộc vào số lượng khách hàng mà bạn có với các kết nối mở và có hay không bạn đang sử dụng kết nối tổng hợp dưới bất kỳ hình thức nào.
Nếu bạn là hệ thống ba cấp và tầng giữa của bạn đã bật tính năng tổng hợp kết nối thì cài đặt ứng dụng khách sẽ không được áp dụng. Nếu bạn không sử dụng một tầng giữa, bây giờ sẽ là thời gian để xem xét nó nếu bạn đang lo lắng về số lượng kết nối đến máy chủ như tầng giữa này sẽ giúp bạn quản lý nó tốt hơn nhiều.
Mọi kết nối mở đều ăn một lượng bộ nhớ nhất định trên máy chủ và thêm một chút phí. Với một hệ thống hai tầng mà khách hàng đang nói thẳng với máy chủ thì bạn cần phải xem xét các thông số kỹ thuật của máy chủ và số lượng máy khách để xem liệu việc mở kết nối có đáng giá hay không. Nếu bạn là một hệ thống hai tầng và bạn có hàng nghìn khách hàng đang hoạt động thì có thể bạn không muốn giữ tất cả chúng mở ... nếu bạn là một hệ thống hai tầng và chỉ có vài chục khách hàng, thì hãy giữ chúng .
Mở và đóng kết nối của bạn cho mỗi hoạt động kinh doanh
Nếu bạn đang nói về một ứng dụng client/server, tôi muốn giới thiệu đóng mỗi kết nối ngay khi bạn đang sử dụng xong. Trong khi mỗi cá thể ứng dụng riêng lẻ có thể thực hiện một lần truy cập hiệu suất nhỏ mở kết nối, toàn bộ ứng dụng của bạn sẽ mở rộng tốt hơn. Điều này phần nào phụ thuộc vào máy chủ cơ sở dữ liệu bạn đang sử dụng. SQL Server sẽ xử lý các số khác nhau của các kết nối đồng thời dựa trên phần cứng được cài đặt trên đó. Nếu bạn muốn mở rộng ứng dụng khách/máy chủ lên hàng nghìn máy tính để bàn, một máy chủ DB nhỏ có thể không xử lý tất cả các máy tính để bàn có kết nối mở nhưng có thể xử lý hàng nghìn máy tính để bàn chỉ với một số kết nối mở.
Tôi đã thấy bàn tay đầu tiên này vài năm trước. Một ứng dụng đã được triển khai tới một vài phòng ban không có sự cố sau đó được triển khai trên toàn bộ tổ chức. Ứng dụng đã sớm rất, rất chậm. Tổ chức đang xem xét việc mua một phần cứng rất đắt tiền cho máy chủ DB của họ để đạt được một số hiệu suất. Tôi đề nghị họ mở và đóng kết nối db sau mỗi hoạt động kinh doanh. May mắn là họ đã thiết kế ứng dụng để đây không phải là một thay đổi khó khăn. Họ đã thực hiện thay đổi và triển khai nó trong một trong các cập nhật mạng hàng tuần của họ. Qua đêm hiệu suất ứng dụng đã được cải thiện đáng kể. Họ đã tiết kiệm hàng ngàn đô la.
Mặc dù chi tiết cụ thể quan trọng nói chung không có gì sai khi giữ kết nối mở trong thời lượng dài.
Nếu ứng dụng của bạn là kết nối tổng hợp - các khe kết nối trong hồ bơi thường vẫn được kết nối cho đến khi cần.
Ngoài các mô hình cấp phép dựa trên kết nối cực kỳ hiếm, hiện nay việc duy trì các kết nối tự tiêu thụ tài nguyên không đáng kể.
Máy khách SQLServer hoạt động trên TCP gửi phiếu giữ mặt ở khoảng 30 giây. (Keepalives về cơ bản là 0 gói TCP len) ususally concidered neglegable traffic.
Nếu hoạt động trong môi trường có băng thông rất ít hoặc với các liên kết WLAN không đáng tin cậy, việc tăng thời gian lưu giữ TCP có thể giúp tăng cơ hội kết nối thời gian dài hoạt động và giảm lượng 'nhàn rỗi' trên dây.
Có những lý do bạn muốn hoặc không muốn sử dụng các hồ bơi kết nối.
chống việc sử dụng hồ bơi:
Loại bỏ khả năng xảy ra ô nhiễm môi trường - nơi các truy vấn khác đặt tùy chọn môi trường đặc biệt mà có thể cản trở thực hiện truy vấn (XACT_ABORT, giao dịch cách ly levels..etc)
Nếu một cấu hình/giới hạn kết nối được cấp phép có hiệu lực trong các kết nối không hoạt động trong ứng dụng của bạn là các kết nối không có sẵn để sử dụng bởi các ứng dụng khác.
Against kết nối mỗi lần:
thiết lập kết nối (thiết lập kết nối đặc biệt là an toàn) đòi hỏi một số chuyến đi vòng bổ sung giữa client và server - chuyến đi vòng có xu hướng trở thành một kẻ giết người hiệu suất cho các ứng dụng mạng WAN.
Tôi nghĩ anh ấy đang nói về các tình huống khi mỗi khách hàng có kết nối riêng của họ trực tiếp với db.Trong trường hợp đó, kết nối tổng hợp sẽ không giúp đỡ ... –
Kết nối tổng hợp là phía máy khách, vậy tại sao nó không giúp đỡ trong tình huống này? – hangy
Mở kết nối và giữ nó, không cần gộp. – liggett78