[Ruby] Per user IO connections in Rails?

[Scott Windsor]

On Thu, May 22, 2008 at 8:47 AM, Atom Powers <atom.powers at gmail.com> wrote:

> On Wed, May 21, 2008 at 5:11 PM, Scott Windsor <swindsor at gmail.com> wrote:
>
> > If you really need to keep around these LDAP connections on a per-user
> > basis, you really want to create a connection pool that stores all of
> these
> > connections globally.  You should be careful though, because depending on
> > your deployment configuration, you could run into contention issues with
> > multiple threads accessing the same pool.  Additionally, keeping all of
> > these connections will be expensive, so you'll want to ensure that you
> have
> > a good way of cleaning up after them after they've been idle for some
> time.
> >
>
> Thank you, I think I found a way to work with a connection pool.
> Unfortunately I have no idea how threads work, so I wouldn't even be able
> to
> guess if I will have contention issues. But I'll have to work on that
> later.
>

If you're using rails with a standard deployment (mongrel or fastcgi), you
should be "ok".  Rails locks each request with a mutex so that you shouldn't
have to worry about it.  Just be mindful that each rails instance has it's
own connection pool - so if you have a large number of rails processing
running on multiple hosts, there's no guarantee that this pool will be used
for a given request (unless you've made your request dispatching smarter).


> > The other alternative is to avoid keeping a connection pool and cache
> > whatever data you need from ldap in the user's session.  You don't want
> > store anything other than data in the session, and you should make sure
> > that
> > whatever session storage solution you pick either has enough room to
> store
> > the data you need (in the case of using cookie storage), or is going to
> be
> > faster than going back out to ldap (in the case of database storage or
> > memcache).
>
>
> Well, I *really* don't want to store the password in the session hash,
> which
> would be required to re-create the ldap connection. And caching ldap data
> in
> a database seems excessively wasteful and not at all DRY.
>

Storing the password in the session does seem like a bad idea for security
reasons.  What I was suggesting is that if you are using ldap purely for
authentication, then you can store a flag in the session to indicate that a
user has been authenticated.

FYI, you don't always have to user that is authenticating to make the ldap
requests.   What I've used in the past is a generic user account in ldap
that can make queries on behalf of the logged in users.  You first
authenticate your users with ldap (using their login & password), set a flag
in their session, then make all subsequent queries with the generic user
connection (who's login and password is saved in your configuration of your
rails app).  At this point, each rails app only needs a single ldap
connection, and can share them across different user requests without having
to re-establish a connection.   But, this may or may not work for you
depending on what you're trying to do and how ldap is set up for you.

- scott

>
> --
> --
> Perfection is just a word I use occasionally with mustard.
> --Atom Powers--
> _______________________________________________
> Ruby at zenspider.com - Seattle.rb non-commercial list
> http://www.zenspider.com/seattle.rb
> http://www.zenspider.com/mailman/listinfo/ruby
>