Re: More than pessimistic record locking needed...
- From: "John Timney \(MVP\)" <x_john@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 27 Jun 2006 23:13:56 +0100
"master" <master@xxxxxxxxxx> wrote in message
news:u$QBt4fmGHA.4076@xxxxxxxxxxxxxxxxxxxxxxx
Adding a timeout checking to my solution seems quite easy - a datetime
field
should be added to tLocks table, each record will be added with the
current
time. Each transaction would then start with deleting records that are
timed-out, i.e. the records whose datetime field is older than a session
timeout...
Potential progress then!
That would be nice, provided the whle solution worked ;-). But the users
reported it did not :-/.
This is why I am thinking about handling the locking not by the DB but by
the web application instead, using a global application cache and a lock
statement. I assume that each http session has a separate thread, am I
right?
Each session has its own thread safe object but I'm not sure holding
thousands of records in application or session is a good idea. Thats a lot
of work for a collection when a database is probably better optimised for
this type of processing.
Additionally, this solution should be a lot faster than blocking the
database with highly isolated transactions...
Yes - perhaps. More than 1 query can return a select so you can almost
guarentee at some point on a heavy database that you will get concurrency
issues, and you would essentially be recreating db functionality in asp.net.
With the correct locking inside a transaction SQL Server places an exclusive
lock on the page (or the row) so unique marking should be possible - leaving
you free to select exclusively and not worry about update problems due to
work in progress time passing, and reducing your memory overhead in
asp.net..
If I was you, I'd pop into one of the SQL server newsgroups and ask their
advice.
--
Regards
John Timney (MVP)
.
- Follow-Ups:
- Re: More than pessimistic record locking needed...
- From: master
- Re: More than pessimistic record locking needed...
- References:
- More than pessimistic record locking needed...
- From: master
- Re: More than pessimistic record locking needed...
- From: John Timney \(MVP\)
- Re: More than pessimistic record locking needed...
- From: master
- Re: More than pessimistic record locking needed...
- From: master
- More than pessimistic record locking needed...
- Prev by Date: Re: Tutorial Video
- Next by Date: Re: is Connection.close() enough or
- Previous by thread: Re: More than pessimistic record locking needed...
- Next by thread: Re: More than pessimistic record locking needed...
- Index(es):
Relevant Pages
|