September 12, 2005 at 8:47 pm
Probably the last thing a DBA wants to hear is that some system wrote something to be processed and then dropped it without confirming the completion. In a transactional environment, this would constitute a failure of the ACID properties.
Yesterday I wrote about the CIO disclosing too much article and commented there were two interesting things in it. This is the second one, the one that said "This 'fire and forget' approach is killing us".
Yikes!!!! It's killing me just reading about it. I can't believe in a modern environment of any size that people would build a system that assumes something written out would get handled without some type of check or verification. That's just crazy.
And deplorable.
Working in a database environment, you should be aware that anything outside of the database, in your application, between databases, etc., is not necessarily bound inside a transaction unless you code it to be that way. And you have to plan for problems in any system-system communication. Tuxedo, MSMQ, and many more transactional middleware systems exist for precisely these problems.
Maybe Overstock.com should abandon Oracle and implement SQL Server 2005 with it's Service Broker. To prevent the "fire and forget" problem from happening.
Steve Jones
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 13, 2005 at 3:24 pm
Still can't believe my eyes....a suggestion to go away from Oracle to MS for transaction control.....
I can't say I've kept up with all of the advancements in SQL Server 2005, so perhaps there are some big gains there.
You do make a valid point that the coding is really where the transactions have to be "maintained" (Tuxedo, MSMQ, etc), so why would you suggest changing databases, if that isn't really the problem?
Not trying to start an Oracle vs MS war, just curious.
September 14, 2005 at 8:09 am
Just a joke. And the transaction problem is in their other DB, not the Oracle one. They didn't properly implement a queueing system or a verification system, which is their issue.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 14, 2005 at 3:05 pm
The "fire and forget" process model has been a cornerstone of Information Systems since the 70's. Does anybody remember IMS DB/DC and BMP programs on the IBM mainframe ? How about "asyncronous" processes on a Digital VAX in the 80's ? Or even Unix daemons since it's inception Berkley (circa 70's) ?
Good overall system architecture and design (which it appears they have not) should have provided the needed checks and balances (auditing) - not to mention transaction re-execution/recovery capabilty.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
September 24, 2005 at 4:42 am
The problem does NOT seem to be the DB but rather a bad application design. Whatever db you use the problem will always be the same and cannot be "solved" by adding another program to the existing ones.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply