A useful application of DRb

[Kirk Haines]

Just thought I'd share this useful, simple application of DRb.

I have a collection of several web sites and applications that date back 2-3
years which were written using a somewhat different overall architecture than
I use now. Each of these carries a database connection pool with 2-3
connections, all of which, for all applications, go into the same database.

The whole collection of sites and apps are all relatively low to moderate
traffic sites, and could all happily share just a couple database
connections, if they could all access the same connection pool. Each runs as
a seperate process, though....

DRb to the rescue!

-----
require 'drb'
require 'dbi'
require 'iowa/DbPool'
require 'kansas'

exit! if (fork)
Process.setsid
if (child_pid = fork)
puts "PID #{child_pid}"
exit!
end

pool = Iowa:bPool.new('xxxxx','xxxxx','xxxxx','xxxxx','xxxxx',2,60) do |dbh|
ksdbh = KSDatabase.new(dbh)
ksdbh.map_all_tables
ksdbh
end

socket = '/var/run/dbpool/oldpool.sock'
File.unlink(socket) if FileTest.exist? socket
DRb.start_service("drbunix:/#{socket}",pool)
DRb.thread.join
-----

Very simple, and now my apps have a way to share this connection pool.

To each app, I add/change:

-----
require 'drb'
class DRbObject
def ==(val); self.method_missing==,val); end
end
#
# other stuff stuff stuff
#
mysock = '/var/run/dbpool/ann_enigo.sock'
poolsock = 'drbunix://var/run/dbpool/oldpool.sock'
File.unlink(mysock) if FileTest.exist?(mysock)
DRb.start_service("drbunix:/#{mysock}")
@dbpool = DRbObject.new_with_uri(poolsock)
-----

That's it. The app uses @dbpool exactly as it did before, and doesn't need
any other changes to accomodate the fact that the dbpool is actually no
longer local to the process using it.

The only wrinkle was the need to alter the def of == on DRbObject. This is
because Kansas uses Ruby to specify queries:

sodium_chloride = ksdbh.selectChemicals) {|c| c.chemical_name == 'sodium
chloride'}

And since DRbOject already has a == method, the use of == above was never
getting passed via DRb back to the actual Kansas object in the connection
pool. Once that was solved, though, it just worked. Performance is more
than adequate. At least at these loads the additional step to go through is
not discernable in the response times. And it lets me get rid of a pile of
database connections.

DRb is just a treat to use, once one starts to understand it.


Kirk Haines