On 29 January 2010 13:43, listread <listread@cze.com> wrote:
> Would this support the idea of putting a lock column in the table to be
> locked? If an admin had cause to go into a table with a DB gui tool, at
> least he would see the semaphore as a "warning".
>
> The same table would also simplify code and make the sb more portable.
>
> As for speed, you have to query that (those) records to be updated anyway at
> some point - a special lock table would require another query and if it that
> lock table was for ALL the other tables in the system, it would be getting
> more hits than any one table.
>
> This has been very educational for me - thanks for the discussion.
>
You could easily extend this to be table locking. Assuming that the
key is tableid/rowid, then you would need to include logic to handle
tableid/null to indicate the whole table.
Obviously, you can't put a table lock on if another user has a row or
table lock.
It does get a little more messy, but perfectly doable in a single SQL query.
Where you put the lock is pretty much up to you, but the extra columns
have no bearing on the table. They aren't data for that table.
A semaphore table would be small.
You can easily remove all the locks from all the tables/rows simply by
truncating the semaphore table.
The other way around all of this is to not do any locking at all.
Simply log when a row is saved and when you go to save the row include ...
where rows_last_edited_datetime =
the_datetime_I_read_when_I_started_editing_the_row
But I don't like that method. It is first saves wins, rather than locking.
--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
|