ASP applications are generally stateless. That is, they leave no server-side
objects around that must be cleaned up by IIS. Yes, you can design
applications that persist state in the Session state (or elsewhere) but
these limit scalability. A persisted lock is another example of
server-managed state. If you expect SQL Server to maintain the lock, it must
do so on a connection basis. That is, when the connection is closed
(logically or physically), the resources being held for the specific
connection (including its state, cursors and locks) are released as well (at
least they are when the connection is reopened by the next client). This
means that in an ASP application you can't maintain connection-managed
state--there's no guarantee you'll inherit the same connection when you
return and even if you did the connection is reset between uses.
Windows forms applications CAN manage connection state. In this case you can
open a connection and intentionally leave it open. This permits you to
create a pessimistic lock (if you know what you're doing) and even create
server-side cursors. I discuss the details of this technique in my
whitepaper published in my monthly column in Hardcore Visual Basic. See
http://www.betav.com/pinnacle.htm. Basically, you create a repeatable-read
transaction and select the rows to be locked.
I describe all of this in far more detail in my book.
hth
--
____________________________________
Bill Vaughn
MVP, hRD
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.
__________________________________
