Thursday, December 08, 2005

Where MySQL and Oracle are the same...

Say you've developed software on Oracle for a while. You know that if you start a query in SQL*Plus and then kill -9 the process that your query is still running on the server. You've got enough calls from your DBA to know that if you do that, you better call and let him know it's still running. Would you think it's any different on MySQL? Nope.

4 comments:

Anonymous said...

Jeff Hunter said...
Why do pharmco's choose lifestyle drugs over curing diseases?

Um, because it's easier.


And your background working at pharmco's is what? No pill is any easier than another. It's ALL about profitability in the end. If they cured cancer with a pill then society would demand it belong to them, for free. Look at the anthrax scare and how people demanded free Cipro.

Anonymous said...

At various points during execution MySQL checks for aborts, in this case a dropping of the connection. Connection gone, query gone. End of session/
It may take a while, because checking these flags everywhere would just slow everything down...

Jeff Hunter said...

It may take a while, because checking these flags everywhere would just slow everything down...

In my very limited experience with MySQL, I haven't seen this yet. A couple nights ago I got a call from a user saying things were slow. By the time I got to the system, the sysadmins had rebooted it. Later investigation found a user had started queries and kill -9'd the process on their local host and assumed they would be killed on the server. Needless to say, 12 hours later, they weren't.

Roderick said...

More recent versions of Oracle are pretty decent about detecting if a client has been killed. For a Unix client, the closing of the socket is usually enough to tell the server process to stop and clean up after itself (sometimes appears slow if it has to roll back a long transaction, but it will finish eventually). In the worst case the server might be spinning in the middle of a PL/SQL block, but I think having the DBA set up sqlnet.expire_time takes care of most cases (except for local connections maybe -- been awhile since I've tested it).