"B. Flaumenhaft" wrote:
>
> No, the distinct databases will not necessarily be in the same server.
>
> For example, I might have web site A and B using schemas DB1 and DB2,
> both on the same Oracle instance. I might have web site C and D using
> DB3 and DB4, however, on a SQL Server database.
>
> The idea is that each user gets different security (critical for
> hosted applications), and this gives them the ability to do ad hoc
> reporting without restriction on their own database.
>
> Also, if web site A grows really fast (and the others don't), I can
> scale up DB1 by moving it to its own server. Lots of extra flexibilty.
Connection pools are a trade-off between CPUtime and storage and I doubt if it's
really practical to have hundreds of connection pools. Why not connect to the
database in the old way by passing userid and password? CPUtime to access a
database will increase, but the app server will need no per-database
configuration (except to put the database into JNDI).
OK, by doing this you are bypassing some app server features but app servers
weren't designed to accomodate a large and varying number of databases. I'm not
saying your requirement is invalid or that you are wrong to try to use an app
server, just that some breakage is to be expected.
Ian McCallion
Alexis Systems Limited
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
