[Ruby] Per user IO connections in Rails?
Scott Windsor
swindsor at gmail.com
Wed May 21 17:11:23 PDT 2008
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.
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).
- scott
On Wed, May 21, 2008 at 3:15 PM, Atom Powers <atom.powers at gmail.com> wrote:
> I'm stumped.
> I have a rails app that authenticates a user to ldap and uses that
> connection to do searches, updates, etc.
> It works well for one person, but because the only way I know of to store
> the ldap connection is globally, as soon as another person logs in it
> overwrites the connection with a new one with the new user's binding. (I
> use
> the binding to determine the amount of access the user has to the
> directory,
> using openldap acls.)
>
> So, how can I store the ldap connection in a per-user way?
> I can't use session[] because the connection contains IO objects.
> And my ruby/rails is weak.
>
> --
> --
> 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
>
More information about the Ruby
mailing list