>> As already stated, and per my own experience, each thread should have it's >> own connection and do whatever it needs to do there, without interference >> from other threads. > >I appreciate this point. Early prototyping indicated that this might not be >possible for our system, which makes me a little nervous if that is what most >users end up doing. We will >definitely take another look at not sharing >connections. >
Maybe consider creating a pool of "reader" threads that get created at application startup. Each one opens it's very own dedicated connection at the beginning. Also have one "listener" thread that accepts requests and farms them out to the "readers". That way you have control over the number of connections being created and the overhead of connecting is done once at application startup. ___________________________________________ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: h...@scigames.at This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
