|
|
Posted by Jerry Stuckle on 01/24/06 01:02
Iván Sánchez Ortega wrote:
> Jerry Stuckle wrote:
>
>
>>No, don't relay on listeners or events, either. Don't wait on anything
>>you don't absolutely have to. For instance - you may need to wait for
>>another database operation to finish (i.e. updating two tables).
>>
>>But never turn control over to someone else (i.e. wait for an event).
>>What happens if an event gets lost?
>
>
> Well, I'm supposing here that the locking mechanism is good enough to not
> let that happen...
>
> However, what I really meant was "never ever rely on active waiting to do
> important concurrent stuff".
>
Locking in a database is controlled by the application. When the
application issues either a COMMIT or ROLLBACK, all locks are released.
But in the meantime, locks are held. Some databases have a lock timeout
setting. But if the timeout occurs, the only solution the database can
take is to internally issue a ROLLBACK.
In the meantime, any apps needing access to the locked resource may have
to wait (depending on a lot of things such as lock type, request type,
etc.). This could be a relatively long time (i.e. 30 sec.).
Rather, the secret to the high transaction systems is to only hold locks
for the shortest possible time. Gather all possible information you
require ahead of time. Get the locks, update the data and COMMIT.
And never, never, never wait for users while holding locks!
That's how the airlines, banks and other high-transaction systems keep
the throughput up.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|