Hi again! > On Tuesday 19 October 2004 16:03, R. Klemme wrote: > > > Hi, > > > I am developing a web application that accesses MaxDB. > > > > > > The application has several instances, every instance should be > limited > > > to a > > > number of concurrent sessions to one big MaxDB database instance. So, > for > > > example: > > > > > > - Web application Instance "A" should have max. 5 concurrent sessions > > > - Web application Instance "B" should have max. 3 concurrent sessions. > > > > > > How would I do this? I am thinking about giving every web application > > > instance > > > a seperate username for MaxDB (Security is done in the web > application). > > > But > > > is there a way to limit the number of concurrent sessions per user? > > > > I'd do it with connection pools. If you're in Java I think you can even > > configure he pool in server.xml or in some other XML file. I'd guess > you > > can then limit the pool size as well as the number of concurrent > > connections. It's also not very difficult to roll your owl pool impl > that > > deals with these contraints but this problem is so general that I am > nearly > > sure you'll find something out there (or even already built into > tomcat). > > 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. 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? 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. Kind regards robert -- +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
