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.
At 9:42 AM +1100 11/29/00, Jonathan Baker wrote:
>So, you are saying you will have hundreds of connection pools?
>
>If you have the option of putting all the distinct databases in the same DB
>server (which I believe is what you are doing) then you might want to
>consider writing a utility class that takes the Connection object and the
>userid which returns the same Connection pointing to the correct database.
>
>Just a thought...
>
>
>
>Jonathan Baker
>Internet Applications Division
>Sybase, Inc.
>
>
>
>"B. Flaumenhaft" wrote:
>>
>> That might work. Doesn't the working bean still need to be registered
>> to use the final DB JNDI name?
>>
>> For example, say I have two connection pools registered as JNDI
>> DataSources, DbA and DbB. Say I make a stateless session bean, as you
>> suggest, and call it DataSourceFinder. Say I have an OrderBean, which
>> is the "working bean" that needs to retrieve a connection.
>>
>> My working bean will do something like:
>>
>> public Connection
>> getConnection (String inUser)
>> throws ...
>> {
>> InitialContext ctx = new InitialContext ();
>> DataSourceFinder home = (DataSourceFinder)
>> PortableRemoteObject.narrow
>> (ctx.lookup
>> ("java:comp/env/ejb/DataSourceFinder"),
>> DataSourceFinder.class);
>> DirectorySourceFinder finder = home.create ();
>>
>> String jndiName = return
>> finder.findConnectionJNDIName (inUser);
>> DataSource ds = (DataSource) initialContext.lookup
>>(jndiName);
>> return ds.getConnection ();
>> }
>>
>> My finder will query the database or some other configuration source
>> to find the JNDI name for the user in question, e.g. either DbA or
>> DbB. Won't my working bean then need to be registered to use that
>> JNDI source, something like
>>
>> <resource-ref>
>> <res-ref-name>jdbc/DbA</res-ref-name>
>> <res-type>javax.sql.DataSource</res-type>
>> <res-auth>Container</res-auth>
>> </resource-ref>
>>
>> ...? In other words, if I add a new connection pool and register it
>> under a new name like DbC, won't my OrderBean need to register in the
>> XML descriptor a resource-ref to jdbc/DbC? And if I have 30 entity
>> beans and 20 session beans, won't each potentially need to be
>> redeployed with that new database? (Which seems like a big deal to
>> me...)
>>
>> Thanks,
>> Ben
>>
>> >I would create a stateless session bean. Have each bean that needs a
>> >connection to a cache call that bean. Based on the login, and a mapping,
>> >say stored in a RDBMS, have the stateless bean return a String which is the
>> >JNDI name of the cache. Then have the working bean lookup that connection.
>> >
>> >Now you simply add a new connection cache, update the mapping table with
>> >what users get what databases and viola, you're done.
>> >
>> >Dave Wolf
>> >Internet Applications Division
>> >Sybase
>> >
>> >
>> >----- Original Message -----
>> >From: "B. Flaumenhaft" <[EMAIL PROTECTED]>
>> >To: <[EMAIL PROTECTED]>
>> >Sent: Monday, November 27, 2000 5:02 PM
>> >Subject: Multiple connection pools dynamically?
>> >
>> >
>> >> Folks,
>> >>
>> >> I'm struggling with a connection pooling problem.
> > >>
>> >> I have a single host server (or server cluster) that's servicing
>> >> multiple accounts (or instances of the website). Depending on who has
>> >> logged in, I need their beans to access different databases.
>> >>
>> >> For example, if a customer logs in for site A, their OrderHistory
>> >> beans would need to access database A. If a customer logs in for site
>> >> B, their OrderHistory beans would need to access database B.
>> >> Databases A and B might be the same database server or a different
>> >> one, but they need to use different JDBC connect strings.
>> >>
>> >> So far, it's not too tricky; I just register the beans as using both
>> >> connection pools (datasources for A and B).
>> >> How do I dynamically add a new site, though? It's not as simple as
>> >> adding a new data source; I also need to register each bean to use
>> >> that new data source. So if I have several hundred web sites and
>> >> several hundred data sources, I'd need each of several dozen beans to
>> >> use each database. This is a bit of an administration headache, right?
>> >>
>> >> Thoughts? The reason behind this is that I'm trying to have one host
>> >> machine service multiple accounts, kind of an ASP model. If someone
>> >> signs up for our service, I don't want to have to edit a bazillion
>> >> configuration files to add one new schema or instance of the database.
>> >>
>> >> All help is appreciated. I've looked around for this, and I can't
>> >> find anyone who's trying something similar.
>> > >
>> >> Thanks,
>> >> Ben
>> >>
>> >>
>> >===========================================================================
>> >> 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".
>> >>
>> >>
>> >
>> >===========================================================================
>> >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".
>>
>> ===========================================================================
>> 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".
>
>===========================================================================
>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".
===========================================================================
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".
