Well, Mongrel locks Rails with a Sync (Mutex caused leaks on some
platforms) so there should be only one user of your global variable at
any one time.  Also, the threads aren't using your global after the
request is finished and the lock is released since rails is done
dispatching.

But, if you're running multiple Mongrels, then you'll get concurrent
access to your backend server.  Unless that server is written to support
concurrent access then you'll have these kinds of issues.

BTW, have you considered just using DRb?  It's really fast, very easy to
use, and it would probably solve many of these issues.

<snip>
--
Zed A. Shaw


So, can't be a issue with my ConnectionClass, right?

Basically this UNIXSocket that i connect(sorry for confusion, its actually a UNIXSocket ) , is a proxy between actual data vending servers and rails.It serves multiple clients(not only rails client, other clients connect to it using TCPSockets) and is written to support multiple concurrent connections. But if I can confirm that there is no issue, with rails connections, then we can inform the other team(i am not author of this proxy server), that please have a look at your code, and see if its thread safe.

We have been initially using DRb, but there was a issue with connection pooling.Besides, fetching data in real time from data vending servers was costly, hence this  proxy does caching and all that stuff.  As per my understanding, the proxy is written like, for each connection it will create a new thread, and a new thread for putting the data to other data vending servers and another thread for receiving the response and sending back to all the connected clients.It attaches unique ids to each request, to make sure that, no data mis-match occurs.

But if it would have been written with druby, then it would be a little difficult for other clients to connect.

Thanks for help Zed.






_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

Reply via email to