Fei Liu wrote: > Jeroen T. Vermeulen wrote: >> On Wed, July 11, 2007 01:41, Fei Liu wrote: >> >> >>> I just realized my problem was using transactor model within a >>> multi-thread environment...Is there any tutorial or example code using >>> pqxx in a multi-thread application environment? Thanks >>> >> Not yet, and we still need to do a lot of work to include locks. Right >> now libpqxx itself doesn't do any locking. >> >> There are several ways to ensure thread safety for your use of libpqxx: >> >> 1. Do all your database work in a single thread. It saves time on >> establishing multiple connections, too. >> >> 2. Give each thread its own connection, and don't interchange libpqxx >> objects between threads. This may scale better or worse than using a >> single thread, depending on the job. >> >> 3. Lock whenever you access any libpqxx object that may also be accessed >> by other threads. Think of each connection as a separate world, and all >> objects related to that connection are part of that world. Whenever >> multiple threads can step into the same world at the same time, acquire a >> lock that you associate with that world. >> >> The last option is the most flexible, but that also means it's dangerous. >> For example, you must make sure that you don't try to open a transaction >> on a connection while another thread still has a transaction open on the >> same connection. I would use option 3 only for connection pooling. >> >> >> Jeroen >> >> >> > Thanks Jeroen, I am trying to get around with a connection_pool model. I > am getting this error: > what(): FATAL: sorry, too many clients already > > What's the upper limit of concurrent connection pqxx supports? what > freedom do I have to adjust it?
There's no upper limit, as far as I know. This seems to be generated by the Postgres server, you might want to check the server configuration! Cheers, Bart _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
