|
I am using SQL Anywhere 11 and have my database running as a service on Windows XP. The docs only mention connection pooling for the .Net Provider. I am connecting from PowerBuilder using ODBC. I will have multiple instances of the app connecting at the time using the same exact connection parameters. Can this be done? |
|
The complete connection string has to be identical. It includes the APPINFO part in which the process id and thread id is mentioned. So in reality connection pooling is only possible if the connection attempt comes from the same thread in the same process. EDIT: According to this answer by Ian, the above statement is not completely true:
I've been not aware of that important restriction (but haven't used pooling, either). - If so, and given the typical synchronous execution of DB requests - why would one single thread ever use several connections to the same database at the same time (except for differentiating between read-only and read/write access)? - I guess then the built-in pooling is primarily useful for applications that use their own thread pool for database access: Then each thread might re-use its "own" pooled connection when the thread gets re-activated. - Or do I have missed the point? @Volker: Application servers on the web, that's who... with a zillion web connections sharing a few database connections. @Breck: Yes, that's my conclusion. - Don't we all wrote those kind of apps:) Actually my app could be considered a web app server. It is a web server plugin that runs PowerBuilder code. IIS will have a separate thread for each browser request and the PB code will use the same connection string for every request. I just checked and the default for AppInfo is empty string. Also by default an unused connection is closed if unused for 60 seconds. So a lightly used app would probably not use a pooled connection. |
|
I'm not sure but I guess connection pooling as a general product feature has been introduced with SA 12. Cf. the new CPOOL connection parameter. I don't know whether the general ODBC connection pooling (cf. the ODBC Admin's according tab) works with SQL Anywhere (and if so, how well it works). |
Not sure where "connection pooling" comes into play... you can have as many instances of an application connecting that you want, all at the same time, subject to licensing restrictions.