More on queue... Possible Solution...
« previous entry | next entry »
Jun. 28th, 2007 | 09:19 pm
My blog is blocked to those who have a livejournal account. I set it
up this way years ago because I hate dealing with comment bots that
generate SPAM. This means I get a lot of back channel comments on my
posts (aka email, IM, IRC) that you never actually see on the
site... I don't normally post them but this one from email was pretty
interesting:
Another interesting comment came from Jan in IRC. Jan was thinking
we could hack up some SQL and try limiting responses based only
supporting certain index components of the API. Would it work?
Well... only sort of. The "sort of" is the problem I have been
getting all afternoon in comments from people. SQL, at least the core
92 sql that MySQL supports, doesn't have the right semantics.
But!
MySQL supports more then SQL.
http://dev.mysql.com/doc/refman/5.1/en/handler.html
The HANDLER commands don't come up often, there isn't that many COBOL
applications out there that need them (and this is only a partial
joke). But semantics that they provide should work.
I am only partially sure this will work... basically disallow normal SELECT statements, and only allow HANDLER issued commands.
Go and read the Oracle document. Certain aspects of what they are
describing remind me of what Paul is doing with the blob streaming
protocol (which once implemented would make for a good spot to
implement pub/sub and some other out of band communication techniques).
up this way years ago because I hate dealing with comment bots that
generate SPAM. This means I get a lot of back channel comments on my
posts (aka email, IM, IRC) that you never actually see on the
site... I don't normally post them but this one from email was pretty
interesting:
The challenging design issues about queuing are about locking and
indexing, not about the API. The API to look at queues and message
should be SQL (so you can use SQL to access the message properties,
the message history, and the payload or do auditing and tracking),
but the API to modify the queue must be something else to preserve
the integrity of the queue.
Oracle Streams AQ does not support data manipulation language (DML)
operations on a queue table or an associated index-organized table
(IOT), if any. The only supported means of modifying queue tables is
through the supplied APIS (which include PL/SQL stored procedures,
Visual Basic using Oracle Objects for OLE, Java Message Service (JMS)
using the oracle.jms Java package and Internet access using HTTP(S).
You can read about Oracle Streams AQ here:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14257/
aq_intro.htm#sthref14
So queuing mechanisms definitely can be written and nicely integrated
with a SQL database. Really ... it's possible ;-)
Another interesting comment came from Jan in IRC. Jan was thinking
we could hack up some SQL and try limiting responses based only
supporting certain index components of the API. Would it work?
Well... only sort of. The "sort of" is the problem I have been
getting all afternoon in comments from people. SQL, at least the core
92 sql that MySQL supports, doesn't have the right semantics.
But!
MySQL supports more then SQL.
http://dev.mysql.com/doc/refman/5.1/en/handler.html
The HANDLER commands don't come up often, there isn't that many COBOL
applications out there that need them (and this is only a partial
joke). But semantics that they provide should work.
I am only partially sure this will work... basically disallow normal SELECT statements, and only allow HANDLER issued commands.
Go and read the Oracle document. Certain aspects of what they are
describing remind me of what Paul is doing with the blob streaming
protocol (which once implemented would make for a good spot to
implement pub/sub and some other out of band communication techniques).