Comment On I Think I'll Call Them "Transactions"

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. 

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.

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.

Not only it holds  thirteen pages, it also exists in ten additional languages.

"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...

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:

"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.

kuroshin:

lock level 0 = unlocked

lock level 1 = exclusively locked 

lock level 2 = cannot be locked

lock level 3 = superlock

lock level 4 = minilock

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.

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!!) 

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
 

Lovely race condition there.

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

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. 

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 ]

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:

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.

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...

Anonymous:

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

[1] Was Invented Here.

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???

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.

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!

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?

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.

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

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!!) 

-- 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'

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. 

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.

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

Good Lock !

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

"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.

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.

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

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).

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. 

|| P ^^
|| L ||

|| A BRIDGE -> Parking lot

|| T ||

|| F ||

|| O ||

|| R ||

vv M ||

Anonymous:

Two lines, one platform,  one bridge:

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

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

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.

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?