On Tuesday 19 October 2004 21:00, R. Klemme wrote: > Hi again! > > That's very interesting but our situation here is not that simple: We are > > migrating from a native C-Client that accesses via ODBC to Zope (Python). > > The > > Problem is that during the transistion phase both should be able to > > access the database, the C-Client and Zope (via Python) but both should > > have the same pool of concurrent connections. So it would be best if the > > database itself would handle all this. > > Ok, I see. If you don't find an easy solution with the DB limiting access, > you can reconsider the pooling approach. You might even hack together a > simple server (in Ruby or Python) that manages connection counts as > intermediate solution.
Building an own simple server would be a solution, yes. But if there exists an out of the box solution, this would be better, e.g. if it's possible to limit connections per user with MaxDB and let MaxDB queue connections exceeding the limit. > Btw: why do you want to limit the number of db sessions per web app? Why > not an overall limit? Does this have to do with load balancing or ensuring > that no web app starves? Our application consists of serveral instances of the same web application. One instance should not eat up all available connections and - as you wrote - make other instances starve. This scenario is not likely, but possible and I want to prevent it beforehand. > Other approaches to limit load on the db might be reasonably employed - at > least for the transition phase: you can limit the nuber of concurrently > handled web requests. Although that would be a stronger restriction than > the one you want, it might be ok for the transition. That's not that simple: There is only a web application: Some functions are rewritten in Zope, they query the database directly via Zope/Python. Other functions remain in a C library (which access the database) are called from Zope/Python. Both connections should be handled together as they both are integrated in one web application. Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
