Re: ensuring row/table locking

["Martin Cordova S." <mcordova@xxxxxxxxxxxx>]

The logic is portable and the pages will be locked according to the
isolation level. If a database does not implement the required isolation
level, then you may see some changed in behavior between different DBs for
the same batch process. McKoi docs contain a nice explanation of this
mechanism.

Regards,
Martin


----- Original Message -----
From: "Aaron Westendorf" <awestendorf@titan.com>
To: <mckoidb@mckoi.com>
Sent: Tuesday, February 25, 2003 12:23 PM
Subject: Re: ensuring row/table locking


> > Something like:
> > 1) BeginTrans
> >     2) Get Recordset
> >     3) Update Table1
> >     4) Update Table2
> > 5) Commit
>
> Thanks Martin, you correctly understand the problem.  I figured that the
> above would be the direction to head in to properly secure row or table
> locking in a transaction.
>
> So, my question comes down to, what (if anything) needs to be special
> about step 2 to make sure that the DB will lock out a row or table?  If
> I query "SELECT quantity FROM PurchasedStuff WHERE customerId=X and
> item=Y", will this not return until another process has completed step
> 5, and when executed, lock the row(s) returned or the table
> PurchasedStuff?  This is the behavior that I'm looking for, and it needs
> to be cross-platform.  If another DB requires configuration for this to
> work properly, that's ok, as long as I can be assured that Mckoi, Oracle
> and other good DB's support the feature in some way.
>
> Thanks for your help!
> -Aaron
>
> --
>
> Titan Corporation
> 1020 Bay Area Boulevard - Suite 200
> Houston, TX  77058
> (281) 461-2100 x130
> (281) 488-0191 Fax
>
>
>
> ---------------------------------------------------------------
> Mckoi SQL Database mailing list  http://www.mckoi.com/database/
> To unsubscribe, send a message to mckoidb-unsubscribe@mckoi.com
>
>