Hi,

I think a better approach would be using something like sql-relay (SQL Relay is a persistent database connection pooling, proxying and load balancing system for Unix and Linux.) instead of a DBI proxy server written in Perl.

This way your Linux boxes connect to the sql-relay server using one of the provided API's:

    * C
    * C++
    * Perl
    * Python
    * PHP
    * Ruby
    * Java
    * TCL
    * Zope

As you can see on the homepage sql-relay, it is ideal for:

    * speeding up database-driven web-based applications
    * enhancing the scalability of database-driven web-based applications
    * distributing access to replicated databases
    * throttling database access
    * accessing databases from unsupported platforms
    * migrating applications from one database to another 

In my opinion, that would be a better solution, and a stronger one too.

Regards,

Thanks for replying.

I have looked into SQL-relay before, but it doesn't quite solve our problem. One of the reasons that we are using DBI proxy is to get away from FreeTDS. DBI proxy allows the use of ODBC to connect to SQL server, which seems to work better. I know it is possible to do ODBC from Linux, but from the research I have done it looks like it would be rather involved to setup and I haven't found a free ODBC driver for Linux. That's why I was hoping that there was a known fix to DBI proxy.

Thanks for your suggestion.

Hi again,

If it's really a problem from DBD::proxy and not a thing of your code (something missed...) you could try it from another perspective... program your own proxy.

Could be a interesting approach, using POE should not be very complicated, and you can make it using POE::Component::Server::XMLRPC and POE::Component::SimpleDBI

That way your clients communicate to your home-made proxy through XMLRPC and you have some methods on the server which wrap around the querys to the DB connected component... back and forth, and, back and forth...

But should be more simply approach too.

Regards,

|fire| at irc.freenode.net

I like merlyn's disclaimer

For further information about administering and configuring SQL Server installations, you might want to look somewhere like this: http://www.informit.com/guides/guide.asp?g=sqlserver

The problem isn't with SQL server itself. That's actually on a different server. The problem I'm having is with the DBI proxy process that is located on a server by itself.
After each connection the size of the memory taken by the perl process grows by about 3-4 megs and the memory is never given back to the OS after the linux client disconnects from the proxy. So after running for awhile, the perl process ends up taking up 150 megs or more of memory and then stops responding. At that point the process has to be killed and restarted to free the memory and get the process working again.