On Mon, 2003-06-23 at 19:25, Derek Neighbors wrote: > Matthew Vanecek said: > > You lock a table in order to perform updates on the table, in the > > absence of row or page level locks. Standard DBMS practice. Not a > > design flaw--it's a feature, to prevent corruption of data. Lock > > tables, perform updates, unlock tables. Anyone else will get a > > contention error, and either retry their transaction or do other error > > handling. > > Well in my world locking a table causes grief beyond belief. Page locks > are ok, row locks preferred. I think it is a design flaw to lock a table > to update a row. Thus I think in general MySQL as a choice is a design > flaw, but I wanted to avoid that debate. (See Mr. Browne's email earlier > as I share his opinion on MySQL) > > Please read I never said it was silly to 'lock' records, only silly to > 'lock' tables. There is a very significant difference. >
Indeed, and point well made. However, if a DBMS only offers table-level locking, then that's pretty much what you're stuck with. MySQL has table locks, according to the book, but I don't know about row level locking. Postgresql has the "SELECT FOR UPDATE" command that can be used for explicit row locking. The current PG back end uses table locks--I want to replace those with row locks. That will, of course, be something that is pretty far removed from the engine->back end and middle-ware layers. -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ******************************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
