Database Triggered Events in Rails

Rails
1

I’m creating a message queue system, (think JMS message queue)

Basically, I’ll be firing off an http request as soon as a row appears
in a database.

Now in past implementations I’ve done the following.

  1. Polled the database every 0.10 seconds.
  2. If something was there to work, I’d tag it as complete.
  3. Create a separate thread. (no further database hits will made)
  4. Run my Net::HTTP.get_response(), which takes from 0.00001 to 600
    seconds to complete.
  5. Write output to some log file.

What’s gotten me into trouble now, is I want to do touch the database.
Which creates all sorts of havoc in rails when threaded.

I’m pondering using BackgroundDB, but it looks like it’s meant for slow
running tasks, not thousands of messages flying back and forth.

I was also thinking of, not touching the database in the thread, but
posting the results back to a separate instance of the rails app, and
let that instance handle the writes to the database. This seems kludgey
though.

I’ve heard that merb, and some of those are threadsafe, maybe I can have
this piece of it, using that instead?

Or perhaps something else.

Thanks for any response!

2

Hi David,

I may have not quite understood what you are trying to achieve, but I’ll
have a bash at this.

Rather than using rails for the whole solution, you could try a daemon
process [could be ruby, php, python, java, C… does not really matter]
monitoring your db, when you find an interesting record, then execute
another thread to handle both the db updates & the request to your rails
site.

Another way, if your db allows it, you could try a trigger that performs
the db operations, then shelling out to a command prompt to execute the
http request to your rails site [unless you can access a http request
within your db’s psql]

Both ways would work on windows & unix, and would be simplier & more
reliable in my opinion.

rgds,

  • matt.

http://www.tickex.com - the search engine for concert, theatre & sports
tickets.

David H. wrote:

I’m creating a message queue system, (think JMS message queue)

Basically, I’ll be firing off an http request as soon as a row appears
in a database.

Now in past implementations I’ve done the following.

  1. Polled the database every 0.10 seconds.
  2. If something was there to work, I’d tag it as complete.
  3. Create a separate thread. (no further database hits will made)
  4. Run my Net::HTTP.get_response(), which takes from 0.00001 to 600
    seconds to complete.
  5. Write output to some log file.

What’s gotten me into trouble now, is I want to do touch the database.
Which creates all sorts of havoc in rails when threaded.

I’m pondering using BackgroundDB, but it looks like it’s meant for slow
running tasks, not thousands of messages flying back and forth.

I was also thinking of, not touching the database in the thread, but
posting the results back to a separate instance of the rails app, and
let that instance handle the writes to the database. This seems kludgey
though.

I’ve heard that merb, and some of those are threadsafe, maybe I can have
this piece of it, using that instead?

Or perhaps something else.

Thanks for any response!