Suppose you want to send a message from one SQL session to one or more other sessions, like "Hey, session#13, here is the latest figure for your calculation, please acknowledge". I'll say what Oracle and EnterpriseDB and DB2 do, then rate the various ways to implement something similar in MySQL and MariaDB, and finish with a demo of the procedure that we use, which is available as part of an open-source package.
DBMS_PIPE.PACK_MESSAGE('message'); SET status = DBMS_PIPE.SEND_MESSAGE('channel#1'); SET status = DBMS_PIPE.RECEIVE_MESSAGE('channel#1'); DBMS_PIPE.UNPACK_MESSAGE(target_variable);
The idea is that PACK_MESSAGE prepares the message, SEND_MESSAGE ships the message on a channel, RECEIVE_MESSAGE receives something on a channel, and UNPACK_MESSAGE puts a received message in a variable. The whole package is called DBMS_PIPE because "pipe" is a common word when the topic is Inter-process communication.
MySQL and MariaDB don't have DBMS_PIPE, but it's possible to write it as an SQL stored procedure. I did, while working for Hewlett-Packard. Before saying "here it is", I want to share the agony that we endured when deciding what, at the lowest level, would be the best mechanism.
The criteria are:
size -- how many bits can a message contain? isolation -- how many conversations can take place simultaneously? privilege -- how specific is the authorization, if any? is eavesdropping easy? danger -- what are the chances of fouling up some other process? reliability -- can messages be delayed or destroyed? utility -- can it be used at any time regardless of what's gone before?
There is no "overhead" criterion because messaging should be rare.
These are the 5 candidate mechanisms.
Session#1 INSERTs to a table, Session#2 SELECTs from the table.
Rating: size=good, isolation=good, privilege=good, danger=low, reliability=good.
But utility=terrible. First: with some storage engines you have to COMMIT in order to send and this might not be a time that you want to COMMIT. Second and more important: there's a bit of fine print in the MySQL Reference Manual:
A stored function acquires table locks before executing, to avoid inconsistency in the binary log due to mismatch of the order in which statements execute and when they appear in the log.
Think about it. It means that you can't read a message that's sent by a function while the function is running. And you can't work around that by writing the messaging code in a stored procedure -- there's no guarantee that the stored procedure won't be called from a function.
Session#1 uses SELECT ... INTO OUTFILE. Session#2 says LOAD_FILE.
(We don't consider LOAD DATA because it won't work in stored procedures.)
Rating: size=good, isolation=good, privilege=good, utility=good.
But danger=high, reliability=bad. The problem is that you can't overwrite a file, so the messages would pile up indefinitely.
Session#1 says SELECT SLEEP(0.5),'message'. Session#2 says SELECT from information_schema.processlist.
Rating: size=bad, isolation=bad, privilege=good, danger=low, utility=bad.
This is okay for short messages if you're not worried about eavesdropping. But notice that the message can only be a literal, like 'message'. It cannot always be a variable, because then it's dynamic SQL, and dynamic SQL is illegal in functions, and now you've got the same problem as with mechanism number 1.
Session#1 says GET_LOCK(). Session#2 says IS_USED_LOCK().
Rating: size=bad, isolation=good, privilege=good, danger=low, utility=good.
Technically reliability=low because the message disappears when the server goes down, but in many situations that would actually be a good thing. The rating "size=bad" is easy to understand: effectively there's only one bit of information (yes/no) that Session#2 is getting by checking IS_USED_LOCK(). However, one-bit signals are great for lots of applications so this would still fit in a toolkit if it weren't for The Great GET_LOCK Showstopper. Namely, you can only have one GET_LOCK at a time.
Now for the good news. Multiple GET_LOCK invocations are on their way. The person to thank (and I say "thank" because this was a contribution done to the whole community) is Konstantin Osipov, who wrote a patch and a blog post -- "MySQL: multiple user level locks per connection". As I understand matters, this was a basis for the code that is coming in a future MySQL version and is now in the MySQL 5.7.5 manual. Konstantin Osipov, by the way, nowadays writes for the Tarantool NoSQL DBMS and Lua application server, to which I am pleased to contribute in small ways.
5. System variables.
Session#1 says SET @@variable_name = 'message'. Session#2 says target = @@variable_name.
Rating: size=bad, isolation=good, privilege=good, danger=high, utility=good.
The system variable must be a string, must be dynamically writable, and must not change the server's behaviour if you write a bad value. Only one item does all that: @@init_connect. It's actually easy to ensure that changes to @@init_connect won't affect its official purpose -- just put the message /* inside a comment */. However, I still rate it as danger=high because anybody could overwrite the message inadvertently.
And the winner, as far as we're concerned, is ... #5 System variables. Remember, Ocelot is supplying a debugger for MySQL/MariaDB routines. It would be a pretty poor debugger that used a message mechanism that wouldn't work with functions, so mechanism#1 and mechanism#3 are out. The GET_LOCK of mechanism#4 is in fact used by a different debugger, but in my opinion that means it's hard to have two debugger sessions on the same server, or to run without pausing after every statement. So our implementation involves setting @@init_connect.
If you want to see our implementation, here is how (on Linux).
Download, install, and start ocelotgui. The instructions are in the
README.md file at https://github.com/ocelot-inc/ocelotgui (just scroll past the list of files). Connect to a MySQL/MariaDB server as a user with privileges to create databases and tables, and execute routines. Then type in, on the statement widget
After this, you actually won't need ocelotgui any more. So, although I think the real "demo" would be to use the debugger now that you've installed it, I'll show how to use pipes with the mysql client instead.
Start a shell. Start mysql. You need the SUPER privilege, and the EXECUTE privilege for routines in the xxxmdbug database. Send a message.
MariaDB [(none)]> call xxxmdbug.dbms_pipe_send('channel#1','message'); Query OK, 0 rows affected (0.00 sec)
Start a second shell. Receive a message.
MariaDB [(none)]> call xxxmdbug.dbms_pipe_receive -> ('channel#1',1,@message_part_1,@message_part_2); Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> select @message_part_1; +-----------------+ | @message_part_1 | +-----------------+ | message | +-----------------+ 1 row in set (0.00 sec)
You can see how it's implemented by saying
SELECT * FROM information_schema.routines WHERE routine_schema = 'xxxmdbug' AND routine_name like 'dbms_pipe_%';
The dbms_pipe_send and dbms_pipe_receive routines are GPL and copyrighted by Hewlett-Packard.
I might not moderate comments on this blog while on vacation. Tomorrow I leave for Reykjavik, Amsterdam and London.