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".
