Re: [PHP-DB] FW: semaphores WAS: [PHP-DB] Automatic logoff
On 29 January 2010 13:43, listread 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 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] FW: semaphores WAS: [PHP-DB] Automatic logoff
On 1/28/2010 3:57 PM, Richard Quadling wrote: On 28 January 2010 21:38, Daevid Vincent wrote: An intersting synopsis of "Semaphores". I've done similar things in the past, but never knew this is what I was doing. LOL. Just like I've built an uber XML parser/editor and didn't know that I actually built a "Factory". Ahhh... good old data structures -- they didn't teach these things when I was in college (20+ years ago). I particularly found this part interesting as I hadn't considered this, "What you _DON'T_ do, is see if the lock is already there before trying to write one. No need and provides the possibility for another user, using the same code, to be interleaved." I am assuming (and correct me if I'm wrong) as you will get a race condition (on a sufficiently large system) wherein, two users check "is there a directory lock", and the system responds "No" to each, and then the code attempts to create a directory. Then one of them gets a lock granted (i.e a directory) and since 'there can be only one' [highlander reference] the other one THINKS they got the lock (too). Doh! What happens in code depends upon the code. If the code doesn't test the result of assigning the lock, then there is no lock. Every write will overwrite whatever was previously written if all users use the same code. And there is the major flaw of distributed or client initiated semaphoring. It is entirely possible for you to open up your DB gui tool and amend the data. Completely bypassing the semaphoring. >>> 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. - Ron >>> So, whilst semaphoring is really useful for long edits, it isn't perfect. But as long as all code use the same semaphoring logic, then it is fine. The wiki page is also interesting and I'd always heard these terms, but never really knew what they were in a practical sense: "A mutex is a binary semaphore that usually incorporates extra features, such as ownership, priority inversion protection or recursivity. The differences between mutexes and semaphores are operating system dependent, though mutexes are implemented by specialized and faster routines. Mutexes are meant to be used for mutual exclusion (post/release operation is restricted to thread which called pend/acquire) only and binary semaphores are meant to be used for event notification (post-ability from any thread) and mutual exclusion. Events are also sometimes called event semaphores and are used for event notification." And this also helped to clarify: http://stackoverflow.com/questions/62814/difference-between-binary-semaphor e-and-mutex Ha! Toilets. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] FW: semaphores WAS: [PHP-DB] Automatic logoff
On 28 January 2010 21:38, Daevid Vincent wrote: > An intersting synopsis of "Semaphores". I've done similar things in the > past, but never knew this is what I was doing. LOL. Just like I've built an > uber XML parser/editor and didn't know that I actually built a "Factory". > Ahhh... good old data structures -- they didn't teach these things when > I was in college (20+ years ago). > > I particularly found this part interesting as I hadn't considered this, > "What you _DON'T_ do, is see if the lock is already there before trying to > write one. No need and provides the possibility for another user, > using the same code, to be interleaved." I am assuming (and correct me if > I'm wrong) as you will get a race condition (on a sufficiently large > system) wherein, two users check "is there a directory lock", and the > system responds "No" to each, and then the code attempts to create a > directory. Then one of them gets a lock granted (i.e a directory) and since > 'there can be only one' [highlander reference] the other one THINKS they > got the lock (too). Doh! What happens in code depends upon the code. If the code doesn't test the result of assigning the lock, then there is no lock. Every write will overwrite whatever was previously written if all users use the same code. And there is the major flaw of distributed or client initiated semaphoring. It is entirely possible for you to open up your DB gui tool and amend the data. Completely bypassing the semaphoring. So, whilst semaphoring is really useful for long edits, it isn't perfect. But as long as all code use the same semaphoring logic, then it is fine. > The wiki page is also interesting and I'd always heard these terms, but > never really knew what they were in a practical sense: "A mutex is a binary > semaphore that usually incorporates extra features, such as ownership, > priority inversion protection or recursivity. The differences between > mutexes and semaphores are operating system dependent, though mutexes are > implemented by specialized and faster routines. Mutexes are meant to be > used for mutual exclusion (post/release operation is restricted to thread > which called pend/acquire) only and binary semaphores are meant to be used > for event notification (post-ability from any thread) and mutual exclusion. > Events are also sometimes called event semaphores and are used for event > notification." > > And this also helped to clarify: > http://stackoverflow.com/questions/62814/difference-between-binary-semaphor > e-and-mutex > Ha! Toilets. -- - 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 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php