W
William \(Bill\) Vaughn
Sure, anything is possible. But the reason we accept the limited UI
capabilities of HTML-based UI is for scalability. This implies (but does not
require) stateless design. The problem with these "occasionally connected"
clients is state management. When do you clean up after them? There are a
litany of other issues as well as you well know.
Client/server architectures have been around for decades. They have been
scaled to thousands of users and well beyond what many companies thought
they would ever need. They lend themselves to server farms and can work very
well in many, many companies.
I'll grant that using a "single" connection and managing it yourself in code
is problematic. However, client/server applications can (and do) open more
than one connection and can effectively leverage the connection pool--albeit
in a limited way. Part of the reason is that opening and closing connections
is not free. Just because you can open a pooled connection does not mean the
security credentials aren't re-verified (unless you're using SQL Server
security). This takes time (albeit not much if things are working well), but
it can add up. That said, pooling connections does make sense for
client/server but only if you plan to use multiple connections and one must
maintain state. The applications I've implemented in production and those
I've helped with have often used a multiple-connection approach. One
persistent connection to maintain server-state and another to perform
updates or other back-door operations. Using this approach, transactions
were not an issue. While MARS helps with this, it too has issues. I still
prefer multiple connections. Sure, this consumes more connections on the
server. So what? Consider that most (by far) multi-user rigs have to support
hundreds (not thousands) of users. However, the newer engines and hardware
can support far more connected users than ever. We've supported thousands of
users on a 386/33 running OS/2 and SQL Server--I expect that a P5/3.0
running Windows Server 2003 and SQL Server 2000 can support far more than
that.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
capabilities of HTML-based UI is for scalability. This implies (but does not
require) stateless design. The problem with these "occasionally connected"
clients is state management. When do you clean up after them? There are a
litany of other issues as well as you well know.
Client/server architectures have been around for decades. They have been
scaled to thousands of users and well beyond what many companies thought
they would ever need. They lend themselves to server farms and can work very
well in many, many companies.
I'll grant that using a "single" connection and managing it yourself in code
is problematic. However, client/server applications can (and do) open more
than one connection and can effectively leverage the connection pool--albeit
in a limited way. Part of the reason is that opening and closing connections
is not free. Just because you can open a pooled connection does not mean the
security credentials aren't re-verified (unless you're using SQL Server
security). This takes time (albeit not much if things are working well), but
it can add up. That said, pooling connections does make sense for
client/server but only if you plan to use multiple connections and one must
maintain state. The applications I've implemented in production and those
I've helped with have often used a multiple-connection approach. One
persistent connection to maintain server-state and another to perform
updates or other back-door operations. Using this approach, transactions
were not an issue. While MARS helps with this, it too has issues. I still
prefer multiple connections. Sure, this consumes more connections on the
server. So what? Consider that most (by far) multi-user rigs have to support
hundreds (not thousands) of users. However, the newer engines and hardware
can support far more connected users than ever. We've supported thousands of
users on a 386/33 running OS/2 and SQL Server--I expect that a P5/3.0
running Windows Server 2003 and SQL Server 2000 can support far more than
that.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________