[Iowa-general] Using Iowa with Activerecord

[Kirk Haines]

On Sun, 03 Oct 2004 21:56:35 +0200, Thomas Uehlinger wrote

> I'm always getting errors like this one:
> Broken pipe: SELECT * FROM people 
> /usr/lib/ruby/site_ruby/1.8/active_record/connection_adapters/abstract_adap
ter.rb:240:in 
`log' /usr/lib/ruby/site_ruby/1.8/active_record/connection_adapters/mysql_ada
pter.rb:119:in 
`select' /usr/lib/ruby/site_ruby/1.8/active_record/connection_adapters/mysql_
adapter.rb:40:in

Hmmm.  I don't have a recent version of ActiveRecord on hand right now for 
me to check this myself.  Could you paste into an email the context around 
each of the line numbers mentioned above?  Broken Pipe is an interesting 
error.  It suggests to me that AR's connection to the db is going away under 
it or something, but I'm not sure.  So I'm curious about what, exactly, is 
throwing that exception.

> But they occur only randomly if Iowa page makes serveral Activerecord
> lookups. So I guess this could be a threading problem or similar. 
> But I don't know how I could cope with that since I cannot use 
> Iowa's DbPool feature with Activerecord because I have to set the DB 
> connection globally:

It's been months since I've looked at ActiveRecord, so help me out, here.  
Is the problem above an shortcoming of DbPool?

There's a bit of functionality that I use all of the time with Kansas, but 
probably isn't documented yet, that may or may not help.

The dbpool is _really_ not a lot different than a generic object pool.  Down 
the road, in fact, I should probably take the baby step to genericize it a 
bit and then make DbPool a subclass of a more generic object pool class.  
Anyway, all it is doing is caching multiple seperate database connections.  
That way one can keep multiple threads from blocking behind a single slow 
query, for instance.  Anyway, if one passes a block into the initialization 
of a DbPool, then after each database handle is created, it will be passed 
back into the block.  The block can do anything that it wants to with the 
handle, and whatever the block returns is what is actually cached.

You'd have to pass DbPool.new a valid set of connection information for your 
database, even if you weren't actually going to use the connections the db 
pool created (since AR isn't going to want a DBI connection), other than 
being philosophically a bit ugly to create them and then let them drop and 
be destroyed, I see no reason why one could not do something like this:

@dbpool = Iowa::DbPool.new('Mysql','localhost','mydb','myid','mypassword',
  3,300) {|dbh|
  # Create an AR instance and let the block return it.  The dbpool will
  # then actually cache the AR instances.
}

That would create 3 AR instances, and assuming that @dbpool is setup as an 
accessor to your application, you could access them in your code like this:

application.dbpool.getConnection do |ar|
  ar.do_whatever
end

Unless I am misunderstanding something, that should work.  Personally, 
though, I'd want to try to track down what is causing that broken pipe 
exception before going ahead and trying this, though.

Let me know if there's anything that I can do to help.

Kirk Haines