• Bob Philhower (unregistered)

    I'd like to see a list of the 17 times that solving the "meta-problem" was useful.

  • Glenn (unregistered) in reply to Bob Philhower

    Anonymous:
    I'd like to see a list of the 17 times that solving the "meta-problem" was useful.

    Unfortunately, they all occurred in 1959, and the wired patch panels were eventually recycled. 

  • Kluge Doctor (unregistered) in reply to Glenn
    Anonymous:

    Anonymous:
    I'd like to see a list of the 17 times that solving the "meta-problem" was useful.

    Unfortunately, they all occurred in 1959, and the wired patch panels were eventually recycled. 

    No, they are called technology break throughs, like going from  VHS to DVD.

  • tanisha (unregistered)
    Alex Papadimoulis:

    <font size="-1">* I would have linked to the Wikipedia for these anti-patterns, but for some reason, there&#39;s no article on them. I assume everyone was just too busy contributing to the thirteen-page <strike>article</strike> dissertation on the <a href="http://en.wikipedia.org/wiki/Chocobo" target="_blank">Chocobo</a>,&nbsp;the fictional bird from the Final Fantasy video game series.</font>

     

    Not only it holds  <font size="-1">thirteen pages, it also exists in ten additional languages. <br></font>

  • ewhac (unregistered)

    "Hey!  I remember this thing from my undergraduate week when we skimmed over Doug Comer's XINU book.  I think they were called 'metaphores'..."

    Bloody amateurs...

  • eli (unregistered)

    Inner-Platform Effect is also known (perhaps more correctly) as Second-System Effect: http://en.wikipedia.org/wiki/Second_system_syndrome

  • kuroshin (cs)
    Alex Papadimoulis:

    His transactional system was built on top of SQL Server 2000 and involved using a table called db__locks which had a row for each table in the database and contained the table's name and a lock level of 0 (not locked) or 1 (exclusively locked). Obviously, he had big expansion plans for the future.

    Ok, smart Alec. You really killed the fun before they started on it.

    lock level 0 = unlocked

    lock level 1 = exclusively locked 

    lock level 2 = cannot be locked

    lock level 3 = superlock

    lock level 4 = minilock 

    Alex Papadimoulis:

    Fun fact: this transactional system comes with an admin utility to reset the db__Locks table if needed.

    Another fun fact: on-call developers use this utility fairly often in the middle of the night when they're woken up by a support call

    Those on-call developers may be script readers. Over here, IT support staff are called engineers, mere programmers are called users, engineers are called consultants........

    Reminds me of Assenture and their thousand strong team full of architects.

    Anyway, Rob's predecessor may not have created that fun utility. That's usually the sign of someone continuing to use the virtual lock without understanding the WTF nature of it, or maybe management was Chocoboed into believing that the virtual lock was really useful.

  • Anonymous Coward (unregistered)

    Let's not forget WP's treatment of Anti-patterns in general. http://en.wikipedia.org/wiki/Anti-pattern There's an entire category of 61 logged anti-patterns, too. Should be good fodder to find SOMETHING to link to in the future. http://en.wikipedia.org/wiki/Category:Anti-patterns

  • Danack (unregistered) in reply to Bob Philhower

    <I>I would have linked to the Wikipedia for these anti-patterns, but for some reason, there's no article on them.</i>

    Your Wikipedia search powers are weak, old man.

    http://en.wikipedia.org/wiki/Anti-pattern

  • HatTrick1914 (unregistered) in reply to ewhac
    Anonymous:

    "Hey!  I remember this thing from my undergraduate week when we skimmed over Doug Comer's XINU book.  I think they were called 'metaphores'..."

    Bloody amateurs...

    Oh they may not be amateurs, I worked for a company that had an off the shelf quality monitoring system that did the exact same thing. It was developed by people that had 20+ years experience each. And if that wasn't bad enough they also had no clue what normalized data was, everything was stored in a flat table with humdreds of fields. After years of expansion they reached the limits of the number of fields you could have in a single table.

  • Fruny (unregistered) in reply to kuroshin
    kuroshin:
    lock level 0 = unlocked

    lock level 1 = exclusively locked 

    lock level 2 = cannot be locked

    lock level 3 = superlock

    lock level 4 = minilock

    lock level 5 = record file not found

  • kuroshin (cs) in reply to eli

    Anonymous:
    Inner-Platform Effect is also known (perhaps more correctly) as Second-System Effect: http://en.wikipedia.org/wiki/Second_system_syndrome

    If I'm not wrong, I'm working on reversing that effect in one of our systems here.

    Too bad, I've got to hide all the ugly stuff instead of refactoring it or writing from scratch.

  • GettinSadda (cs) in reply to eli

    OMG!

    One of the fundamental aspects of the implementation of any locking strategy is that the "discover the item is not currently locked - lock it ourselves" bit has to be atomic... otherwise two locks can get set at the same time!

    This was doomed to failure from the start (and as pointed out... pointless!!) 

  • Volmarias (cs) in reply to Anonymous Coward

    Sweet jesus. If I was this guy's employer, I'd not only fire him, but sue him for the wages they paid him for deceiving the company into believing that he was competant. Then I'd fire whoever hired this guy, because they're clearly not competant at decision making

  • John Bigboote (cs) in reply to Fruny
    Anonymous:
    kuroshin:
    lock level 0 = unlocked

    lock level 1 = exclusively locked 

    lock level 2 = cannot be locked

    lock level 3 = superlock

    lock level 4 = minilock

    lock level 5 = record file not found

    lock level 6 = headlock

    lock level 7 = cockb-lock
     

  • DontKnow (cs)

    Lovely race condition there.

    Next they have to implement message queues and events via database tables to further increase serialization.

  • sammybaby (cs)

    Alex Papadimoulis:
    * I would have linked to the Wikipedia for these anti-patterns, but for some reason, there's no article on them. I assume everyone was just too busy contributing to the thirteen-page article dissertation on the Chocobo, the fictional bird from the Final Fantasy video game series.



    What? No love for the Chocobo? For shame, Alex. 

  • kuroshin (cs) in reply to Fruny
    Anonymous:
    kuroshin:
    lock level 0 = unlocked

    lock level 1 = exclusively locked 

    lock level 2 = cannot be locked

    lock level 3 = superlock

    lock level 4 = minilock

    lock level 5 = record file not found

    Uh wait, I forgot the most important ones :

    lock level -1 : locklock [ A lock on an existing lock, smarty ]

    lock level -2 : recursivelock [ Surely, something enterprisey has to have recursion ]
  • John Bigboote (cs) in reply to kuroshin
    kuroshin:
    Anonymous:
    kuroshin:
    lock level 0 = unlocked

    lock level 1 = exclusively locked 

    lock level 2 = cannot be locked

    lock level 3 = superlock

    lock level 4 = minilock

    lock level 5 = record file not found

    Uh wait, I forgot the most important ones :

    lock level -1 : locklock [ A lock on an existing lock, smarty ]

    lock level -2 : recursivelock [ Surely, something enterprisey has to have recursion ]

     

    lock level -3: powerlock [A lock that cannot be broken using the admin utility, must be broken by a level 10 DBA with 18 dexterity. Roll for damage.]

  • Colin McGuigan (cs) in reply to kuroshin

    The best part is that the locking logic itself is not transactional, so it's entirely possible for two or more processes to end up with the lock on a table.  Fun!

  • kuroshin (cs) in reply to Colin McGuigan

    Colin McGuigan:
    The best part is that the locking logic itself is not transactional, so it's entirely possible for two or more processes to end up with the lock on a table.  Fun!

    You've pointed out the uselessiness (like truthiness) of the admin utility. The locks are stored in a table that can be locked.

  • spacedman (unregistered)

    uncyclopedia.org has a more compact article on the Chocobo

    I wondered what 'Inner Platform Effect' was. I imagined it was to to with railway stations. If you have two rail lines, you could either have two platforms on the outside of the line, or save money by having a single two-sided platform in the middle of the two lines. But then, ah, you need a tunnel or bridge to get to, which inflates the cost... The Inner Platform Effect. Its probably nothing to do with that...

     

     

     

  • Dazed (unregistered) in reply to eli
    Anonymous:
    Inner-Platform Effect is also known (perhaps more correctly) as Second-System Effect: http://en.wikipedia.org/wiki/Second_system_syndrome

    The Inner-Platform Effect appears to be a WIH [1]. It could very well be (often is?) one of the results of Second-System Syndrome, but AIUI they aren't the same thing.

    [1] Was Invented Here.

  • rmg66 (cs) in reply to ewhac
    Anonymous:

    "Hey!  I remember this thing from my undergraduate week when we skimmed over Doug Comer's XINU book.  I think they were called 'metaphores'..."

    Bloody amateurs...

     Semaphores???

  • DigitalLogic (cs) in reply to kuroshin
    kuroshin:

    Colin McGuigan:
    The best part is that the locking logic itself is not transactional, so it's entirely possible for two or more processes to end up with the lock on a table.  Fun!

    You've pointed out the uselessiness (like truthiness) of the admin utility. The locks are stored in a table that can be locked.



    You can lock the lock table using this locking scheme, but the only thing enforcing that lock is the application code.  So the admin utility simply doesn't check to see if the lock table is locked before unlocking some other table.

    Try saying that three times fast.
  • Cody (unregistered) in reply to kuroshin

    Colin McGuigan:
    The best part is that the locking logic itself is not transactional, so it's entirely possible for two or more processes to end up with the lock on a table.  Fun!

    That was fixed in the update.  Now the lock table is locked when locking a table.
  • rmg66 (cs) in reply to DigitalLogic

    I've wrapped built-in functionality to suit my needs. But Completely re-invent it?

    Imagine what it would look like if he wanted to get to the record-locking level?

  • savar (cs) in reply to eli

    Anonymous:
    Inner-Platform Effect is also known (perhaps more correctly) as Second-System Effect: http://en.wikipedia.org/wiki/Second_system_syndrome

     That's not the same as inner-platform. I think there should be a wikipedia entry about inner-platform.

  • pjsson (cs)

    Alex Papadimoulis:
    ...meta-problem: a problem with the process of creating a solution for the actual problem.

    The following forum post on Joels is already a classic when it comes to describe how silly meta problem solving is, a must read: Why I Hate Frameworks


     

     

  • DigitalLogic (cs) in reply to GettinSadda
    GettinSadda:

    OMG!

    One of the fundamental aspects of the implementation of any locking strategy is that the "discover the item is not currently locked - lock it ourselves" bit has to be atomic... otherwise two locks can get set at the same time!

    This was doomed to failure from the start (and as pointed out... pointless!!) 





    <sarcasm>
    That's an easy fix.


    -- Wait for lock
    SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

    WHILE @LockLevel <> '0'
    BEGIN
        BEGIN TRANSACTION
        SELECT @LockLevel = LockLevel
        FROM db__Locks
        WHERE LockTbl = 'GL_Operations'

        IF @LockLevel <> '0' ROLLBACK TRANSACTION
    END

    -- Set lock
    UPDATE db__Locks
    SET LockLevel = '1'
    WHERE LockTbl = 'GL_Operations'
    COMMIT TRANSACTION

    ... snip whole bunch of code ...

    -- Clear lock
    UPDATE db__Locks
    SET LockLevel = '0'
    WHERE LockTbl = 'GL_Operations'


    P.S - The real WTF is that he didn't put the locking logic in stored procedures.  That would make adding the above fix much easier to implement.

    </sarcasm>
  • Tango Uniform (unregistered) in reply to DigitalLogic

    Here is my question relating to database locks.

    1. User selects a record in a GUI list to edit
    2. System loads data into GUI edit window
    3. 30 minutes go by (while user is editing data in GUI, anyone else trying to edit it gets a message it is locked)
    4. User hits save button
    5. Record in database is updated

    What sort of "locking" mechanism would you use to implement this type of transaction, where a record has been read to be edited by a user, but this might take quite some time?  How would having a limited pool of database connections impact such an implementation?  How would the need to have a portable (between different databases) affect the implementation?

    Basically, I have seen designs that have some sort of "lock" record on tables to indicate the record is in use by some user.  This is not done necessarily to reimplement the concept of a transaction.  In fact, these systems use a database transaction to test and update the lock field to ensure only one user gets the lock.  It is more used for locking a record or set of records in order to allow a user to look at and edit the data, when a pessimistic lock is required.

    In addition, how would one implement a portable optimistic locking scheme.  Most of those I have seen involve having a "last updated" timestamp, where ensuring it hasn't changed is part of the update sql.

    In essense, I have seen a lock flag field used for pessimistic locking, and a timestamp field used for optimistic locking, and have not seen any problems with these techniques.  They seem to be versatile and portable, and don't require holding a database connection for long periods of time while the record is being edited on a GUI.

    Thanks. 

  • Reed (unregistered)

    http://c2.com/cgi/wiki?AntiPattern

    http://c2.com/cgi/wiki?AntiPatternsCatalog

     

    The Inner Platform Effect:  http://thedailywtf.com/forums/69415/ShowPost.aspx

    "The Inner-Platform Effect is a result of designing a system to be so customizable that it ends becoming a poor replica of the platform it was designed with."

     

    It's an over-engineering anti-pattern. Ostensibly it's designed to enable portability or ease future changes but generally ends up just sucking to work with.

     

  • ParkinT (cs)

    After reading this story, all I have to say to Robert Rossney is:

     

    Good Lock !

  • Hinek (unregistered)

    For those who don't know what the Inner-Platform Effect is:

    The Inner-Platform Effect is a result of designing a system to be so customizable that it ends becoming a poor replica of the platform it was designed with. This "customization" of this dynamic inner-platform becomes so complicated that only a programmer (and not the end user) is able to modify it.

    http://thedailywtf.com/forums/69415/ShowPost.aspx

  • Craig (unregistered)

    "Now before all you database developers scream "Use Built-in Transactions!," let me remind you that there are a whole lot of problems associated with built-in database transactions"

    But what about when built-in transactions are insufficient?

    Sybase IQ supports transactions, but only allows one 'writer' thread per table.  This means that if you want to have multiple ways to update a single table you have to 'single-stream' them.

  • Milkshake (unregistered) in reply to rmg66
    rmg66:
    Anonymous:

    "Hey!  I remember this thing from my undergraduate week when we skimmed over Doug Comer's XINU book.  I think they were called 'metaphores'..."

    Bloody amateurs...

     Semaphores???

    Give him a break.  He only skimmed over the book, but obviously that's quite enough to justify him in calling someone else an amateur.

  • Ghost Ware Wizard (cs)

    wtf?! sounds like the weed was smoked a little too much that day.

    use a rdbms and then add layer upon layer of "management" constraints aka *slow* the system down.....

     You Geek Code Something

  • Grog (unregistered)

    Why didn't he use a cursor to iterate over the list of locks? Come on, man!!!

  • Local guy (unregistered) in reply to Ghost Ware Wizard

    Nice to see some code :)

  • RetireBy40 (unregistered)
  • Rich (unregistered) in reply to spacedman
    Anonymous:

    uncyclopedia.org has a more compact article on the Chocobo

    I wondered what 'Inner Platform Effect' was. I imagined it was to to with railway stations. If you have two rail lines, you could either have two platforms on the outside of the line, or save money by having a single two-sided platform in the middle of the two lines. But then, ah, you need a tunnel or bridge to get to, which inflates the cost... The Inner Platform Effect. Its probably nothing to do with that...

     

     

    WTF? If you have the platform between the lines, you need *two* bridges to be able to get anywhere (Unless the lines terminate (Waterloo Station, London) or you have level crossings where you walk across the track (Seen in Italy) which would be as applicable for the "outer platforms" anyway).

     

  • Alistair Wall (cs) in reply to Tango Uniform
    Anonymous:

    Here is my question relating to database locks.

    1. User selects a record in a GUI list to edit
    2. System loads data into GUI edit window
    3. 30 minutes go by (while user is editing data in GUI, anyone else trying to edit it gets a message it is locked)
    4. User hits save button
    5. Record in database is updated

    What sort of "locking" mechanism would you use to implement this type of transaction, where a record has been read to be edited by a user, but this might take quite some time?  How would having a limited pool of database connections impact such an implementation?  How would the need to have a portable (between different databases) affect the implementation?

    Basically, I have seen designs that have some sort of "lock" record on tables to indicate the record is in use by some user.  This is not done necessarily to reimplement the concept of a transaction.  In fact, these systems use a database transaction to test and update the lock field to ensure only one user gets the lock.  It is more used for locking a record or set of records in order to allow a user to look at and edit the data, when a pessimistic lock is required.

    In addition, how would one implement a portable optimistic locking scheme.  Most of those I have seen involve having a "last updated" timestamp, where ensuring it hasn't changed is part of the update sql.

    In essense, I have seen a lock flag field used for pessimistic locking, and a timestamp field used for optimistic locking, and have not seen any problems with these techniques.  They seem to be versatile and portable, and don't require holding a database connection for long periods of time while the record is being edited on a GUI.

    Thanks. 

    The mechanism varies by database, so you would put this in your database-specific layer. In Oracle you would select the system change number pseudo-column, then check the SCN again in the where clause of your update statement. 

     

  • aliethel (unregistered) in reply to tanisha

    I have to ask what does that say about me that I actually read the entire article and enjoyed it?

  • anon (unregistered) in reply to Rich

    Two lines, one platform,  one bridge:

    || P ^^
    || L ||
    || A BRIDGE -> Parking lot
    || T ||
    || F ||
    || O ||
    || R ||
    vv M ||

  • Ripper the Non-Believer (unregistered) in reply to John Bigboote

    Next week:the non-blocking chocoblock.

  • SwordfishBob (unregistered) in reply to anon
    Anonymous:
    Two lines, one platform,  one bridge:

    || P ^^
    || L ||
    || A BRIDGE -> Parking lot
    || T ||
    || F ||
    || O ||
    || R ||
    vv M ||

    Yeah, I recall seeing a few platforms as wobbly as variable-pitch-text-drawings, and with the end falling off..
  • iboB (unregistered) in reply to John Bigboote
    John Bigboote:
    kuroshin:
    Anonymous:
    kuroshin:
    lock level 0 = unlocked

    lock level 1 = exclusively locked 

    lock level 2 = cannot be locked

    lock level 3 = superlock

    lock level 4 = minilock

    lock level 5 = record file not found

    Uh wait, I forgot the most important ones :

    lock level -1 : locklock [ A lock on an existing lock, smarty ]

    lock level -2 : recursivelock [ Surely, something enterprisey has to have recursion ]

     

    lock level -3: powerlock [A lock that cannot be broken using the admin utility, must be broken by a level 10 DBA with 18 dexterity. Roll for damage.]

    lock level 0xFFFFFFFF : division by zero

  • Adam B. (unregistered) in reply to GettinSadda
    GettinSadda:

    OMG!

    One of the fundamental aspects of the implementation of any locking strategy is that the "discover the item is not currently locked - lock it ourselves" bit has to be atomic... otherwise two locks can get set at the same time!

    This was doomed to failure from the start (and as pointed out... pointless!!) 

     

    Actually, you can do it atomically with JDBC (probably ODBC and other mechanisms as well).  Update lock_table set lock_value=1 where lock_value=0 and lock_name="whatever".  If the return value is 1, you got the lock, otherwise no dice. There's even a legitimate (if exceedingly rare) use for this particular WTF. If it's a distributed system and the cost of cleaning up if you find out that the default optimistic working strategy is extremely high, this can be faster by reducing the number of times that you have to clean up.  Of course, this also leads to loads of issues like having to do lock reclamation if a process hangs or dies, deadlock detection and who knows how many other issues.

  • Adam B. (unregistered) in reply to Adam B.

    Oh, forgot that in that case they probably also should have implemented read-locks unless the data is always written after reading it.

  • xcor057 (unregistered) in reply to kuroshin
    kuroshin:
    Anonymous:
    kuroshin:
    lock level 0 = unlocked

    lock level 1 = exclusively locked 

    lock level 2 = cannot be locked

    lock level 3 = superlock

    lock level 4 = minilock

    lock level 5 = record file not found

    Uh wait, I forgot the most important ones :

    lock level -1 : locklock [ A lock on an existing lock, smarty ]

    lock level -2 : recursivelock [ Surely, something enterprisey has to have recursion ]

     recursivelock - A lock that re-locks itself when unlocked?

Leave a comment on “I Think I'll Call Them &quot;Transactions&quot;”

Log In or post as a guest

Replying to comment #:

« Return to Article