Re: Persistent Sessions in DB connection for QZDASOINIT, implemented by Nathan

From: Pete Helgren
The connection pools are tracked by what is called a role ...

It's probably clear to most developers that connection pools offer big performance gains. You don't want to create and destroy connections with every request. You probably won't want to set library lists, perform member overrides, or open and close database tables for every request. Those are relatively resource intensive actions. On the other hand, there seems to be some concern about scalability if the connection is scoped to individual user sessions. So out of curiosity, what criteria do folks use to draw the line?

Another question is how this relates to applications that run within a portal context, where users may launch multiple instances of the same application in separate tabs (using separate inline frames). Say you're comparing the master course / class schedules of each of the high schools in the school district, which involves paging but you don't want the paging performed in one tab (inline frame) to interfere with paging performed in another, even though the same database is being perused in each.

Nathan.