Hmm, let me try again.
The general idea is that the application itself will be deployed with one configured datasource. That datasource will provide database connections to a central "directory DB" of sorts. If the application is ever shutdown or restarted, this should be the only datasource that is immediately available. I would like any/all access to this "directory DB" to be managed by Geronimo (connection pooling, transactions, etc).
Part of the application behavior is to add/remove named "data DBs". This will be done by persisting connection information for these "data DBs" into said "directory DB". Application behavior also includes the ability to make connections to these "data DBs" and using them. I would like any/all access to these "data DBs" to be done via dynamically created datasources that are managed by Geronimo (connection pooling, transactions, etc). I would then access these datasources via any available mechanism (ex. JNDI).
I'd like to be able to handle my connection pooling/management via Geronimo without having to do something that requires manual intervention. For example, every time I create a new "data DB", I don't want to have to manually go into the Geronimo UI to create a new datasource. I also want to ensure that the connection information is not persisted inside Geronimo configurations at shutdown, because the connection information in my "directory DB" is subject to change outside of my application. I want the "directory DB" to be the configuration master. I want to view/manage/monitor the "data DB" pools from Geronimo. I just don't want it saving all of my info on module shutdown.
All code is deployed once. There will be no runtime deployment of new code to go with the new databases, per se.
Does that make more sense?
--
Jimmy Wan
Senior Technical Lead
21st Century Technologies, Inc.
4515 Seton Center Parkway Suite 320
Austin, TX 78759
Phone: 512-342-0010 x249
Email: [EMAIL PROTECTED]
URL: http://www.21technologies.com
The information in this email and in any attachments
is confidential and may be privileged. If you are not the intended recipient,
please destroy this message, delete any copies held on your systems and
notify the sender immediately. You should not retain, copy or use this
email for any purpose, nor disclose all or any part of its content to any
other person.
David Jencks <[EMAIL PROTECTED]> wrote
on 06/26/2006 11:14:33:
> On Jun 26, 2006, at 5:24 AM, [EMAIL PROTECTED] wrote:
> Why don't you dynamically programmatically create
something like an
>
> org.apache.commons.dbcp.BasicDataSource
>
>
> and then just cache the instance of that in a Map for use whenever
> you need it. That way your code is app server indpendent.
>
> That would be app server independent, but it would also preclude any
> container managed transaction features such as use of
> UserTransaction or CMT ejbs. If you don't need any features
like
> these this might well be your simplest solution.
>
> There is no way to bind any such datasource into the java:comp jndi
> namespace and as the contents of this namespace are specified by the
> j2ee spec this is not likely to change.
>
> Can you specify a bit more fully when the configuration info in the
> database is available, when it changes related to when the app is
> deployed/started/stopped, and how you want your program to get the
> reference to the datasources?
>
> thanks
> david jencks
