Hi Koen, Koen Deforche wrote: > The easiest one is to have a database connection per session. > Databases usually (always?) support multiple threads to concurrently > manipulate different connections but only support manipulation of a > connection from one thread, and thus this coincides nicely with Wt's > concurrency support. > This looks like the place to start, thanks. I believe that the application will need to be linked to the "thread aware" versions of the MySQL C libs as well as the MySQL++ ones to be safe.
This was an interesting read; http://tangentsoft.net/mysql++/doc/html/userman/threads.html as was this; http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > If you need to support many concurrent clients, then it may make sense > to use a connection pool per process, since it is often said that > databases scale badly with the number of concurrent connections. Then, > your sessions only borrow an existing connection during the span of a > single transaction. I have no idea whether MySQL++ provides such an > abstraction Yes it does, mysqlpp::ConnectionPool, but I think I will only need to look at this in very high traffic applications. Thanks, Brad ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
