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

As programmers, we derive satisfaction from our ability to create solutions to other peoples' problems. Unfortunately, the problems that we solve aren't the exciting "world-hunger" type, they're more along the lines of, "Sally is spending too much time doing expense reports and would like to automate the process." The inherently boring nature of these business problems lead many programmers to seek out new problems to solve, the most common of which is the meta-problem: a problem with the process of creating a solution for the actual problem. [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: I Think I'll Call Them "Transactions"

2006-10-31 13:29 • by Bob Philhower
I'd like to see a list of the 17 times that solving the "meta-problem" was useful.

Re: I Think I'll Call Them "Transactions"

2006-10-31 13:36 • by Glenn
98793 in reply to 98792

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. 

Re: I Think I'll Call Them "Transactions"

2006-10-31 13:41 • by Kluge Doctor
98795 in reply to 98793
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.

Re: I Think I'll Call Them "Transactions"

2006-10-31 13:44 • by tanisha
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.

Re: I Think I'll Call Them "Transactions"

2006-10-31 13:44 • by ewhac

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

Re: I Think I'll Call Them "Transactions"

2006-10-31 13:46 • by eli
Inner-Platform Effect is also known (perhaps more correctly) as Second-System Effect: http://en.wikipedia.org/wiki/Second_system_syndrome

Re: I Think I'll Call Them "Transactions"

2006-10-31 13:48 • by kuroshin
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.

Re: I Think I'll Call Them "Transactions"

2006-10-31 13:49 • by Anonymous Coward
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

Re: I Think I'll Call Them "Transactions"

2006-10-31 13:50 • by Danack
98801 in reply to 98792
<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

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 13:51 • by HatTrick1914
98802 in reply to 98797
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.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 13:51 • by Fruny
98803 in reply to 98799
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

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 13:52 • by kuroshin
98804 in reply to 98798

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.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 13:52 • by GettinSadda
98805 in reply to 98798

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

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 13:53 • by Volmarias
98806 in reply to 98800
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

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 13:57 • by John Bigboote
98807 in reply to 98803
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
 

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:01 • by DontKnow

Lovely race condition there.

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

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:02 • by sammybaby

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. 

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:02 • by kuroshin
98810 in reply to 98803
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 ]

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:05 • by John Bigboote
98811 in reply to 98810
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.]

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:06 • by Colin McGuigan
98812 in reply to 98810
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!

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:08 • by kuroshin
98813 in reply to 98812

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.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:16 • by spacedman

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

 

 

 

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:19 • by Dazed
98816 in reply to 98798
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.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:23 • by rmg66
98817 in reply to 98797
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???

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:25 • by DigitalLogic
98818 in reply to 98813
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.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:30 • by Cody
98819 in reply to 98813

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.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:31 • by rmg66
98820 in reply to 98818

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?

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:33 • by savar
98821 in reply to 98798

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.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:34 • by pjsson

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


 

 

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:38 • by DigitalLogic
98823 in reply to 98805
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>

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:38 • by Tango Uniform
98824 in reply to 98818

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. 

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 14:50 • by Reed

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.

 

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 15:00 • by ParkinT

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

 

Good Lock !

Inner-Platform Effect

2006-10-31 15:09 • by Hinek

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

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 15:23 • by Craig

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

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 15:26 • by Milkshake
98841 in reply to 98817
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.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 15:29 • by Ghost Ware Wizard

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

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 15:39 • by Grog
Why didn't he use a cursor to iterate over the list of locks? Come on, man!!!

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 15:40 • by Local guy
98847 in reply to 98844
Nice to see some code :)

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 15:45 • by RetireBy40

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 15:50 • by Rich
98851 in reply to 98815
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).

 

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 15:59 • by Alistair Wall
98853 in reply to 98824
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. 

 

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 16:02 • by aliethel
98854 in reply to 98796
I have to ask what does that say about me that I actually read the entire article and enjoyed it?

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 16:02 • by anon
98855 in reply to 98851
Two lines, one platform,  one bridge:



|| P ^^
|| L ||

|| A BRIDGE -> Parking lot

|| T ||

|| F ||

|| O ||

|| R ||

vv M ||


Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 16:24 • by Ripper the Non-Believer
98858 in reply to 98811
Next week:the non-blocking chocoblock.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 16:32 • by SwordfishBob
98861 in reply to 98855
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..

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 16:56 • by iboB
98864 in reply to 98811
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

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 17:05 • by Adam B.
98865 in reply to 98805
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.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 17:09 • by Adam B.
98866 in reply to 98865
Oh, forgot that in that case they probably also should have implemented read-locks unless the data is always written after reading it.

Re: I Think I'll Call Them &quot;Transactions&quot;

2006-10-31 17:11 • by xcor057
98867 in reply to 98810
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?

« PrevPage 1 | Page 2 | Page 3Next »

Add Comment