Dynamic datasource register/unregister

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Dynamic datasource register/unregister

alaley
Hello,

Is it valid to perform dynamic JDBC pool initialization and/or
removing running XAResourceProducers with the help of ResourceRegistrar.unregister(...)?

I have wrote a basic test which executes correctly without any visible problems,
but want to know is it a legal thing in TBM.

The basic test uses the following scenario:

1. Calling TransactionManagerServices.getTransactionManager() to perform initial configuration
   via bitronix-default-config.properties and ds-config.properties to configure some JDBC Datasources.

2. Start normal work with configured Datasources

3. Programmatically create and init new PoolingDataSource:
   PoolingDataSource dynamicPool = new PoolingDataSource();
   dynamicPool.setXXX... - set properties
   dynamicPool.init();

4. Use just created datasource in next UserTransaction

5. Remove some of existing Datasources via
   ResourceRegistrar.unregister(ResourceRegistrar.get(someUniqueName));

6. Continue to use another registered datasources.

Are there any constraints on such approach?
Can 3 and 5 steps be executed within already started UserTransaction
(which of cause does not use just created/removed datasources)?

Many thanks,
Serge.
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic datasource register/unregister

Ludovic Orban
Administrator
Hi,

I don't really get what you're trying to achieve here. Why do you have a resource loader configuration file (I guess this is what ds-config.properties actually is) if you also need to create connection pools manually ? Wouldn't it be more consistent to create all your pools manually ?

Anyway, you'd better not use the ResourceRegistrar API directly as it is only meant to be used internally by the connection pools. Calling init() on a PoolingDataSource will register it in the ResourceRegistrar while calling close() on it will unregister it. Calling ResourceRegistrar.unregister() will only lead to a database connections leak as the connections held by the pool would never get closed.

Also why do you want to create short-lived datasources ? BTM has the flexibility to permit this at anytime since version 1.3 but you have to remember the implications on recovery: a datasource's unique name is used to identify it in the transaction logs. In case of crash, the recovery mechanism will expect the exact same datasource to be recreated with the exact same unique name at some time. If that never happens, you can kiss atomicity goodbye.

Maybe if you explain a bit more what you're doing I could tell you if you're on the safe side or not.

Ludovic
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic datasource register/unregister

alaley
Ludovic Orban пишет:
...
> close() on it will unregister it. Calling ResourceRegistrar.unregister()
> will only lead to a database connections leak as the connections held by the
> pool would never get closed.
Thanks for usefull advice, that's what I've missed.


> Also why do you want to create short-lived datasources ?
...
 > Maybe if you explain a bit more what you're doing I could tell you if
 > you're on the safe side or not.

I have to develop some sort of database manager,
to manage multiple databases. System user must have a ability
to add or remove (actually "detach") database without the whole app
restart/reconfigure. The list of connection params of managed databases
is stored in "master" database and ds-config.properties contains static
configuration for it. When app starts, it performs lookup of connection
params from "master" DB and have to create appropriate Datasources and
make them ready to work for app.
These managed datasources are not short-lived actually,
they MAY (and probably will I hope) live for a long time.
But there is a need to stop some part of app service, let say,
for maintenance without stopping the whole app.


> BTM has the
> flexibility to permit this at anytime since version 1.3 but you have to
> remember the implications on recovery: a datasource's unique name is used to
> identify it in the transaction logs. In case of crash, the recovery
> mechanism will expect the exact same datasource to be recreated with the
> exact same unique name at some time. If that never happens, you can kiss
> atomicity goodbye.
>
clear, thanks for warning.

Thanks for attention and such descriptive answer,
Serge.

PS
I have wrote a simple "Hellow, World!" example
to test BTM + Hibernate as JPA provider.
It is like yours HibernateBTM13.zip,
but ready to use for JPA.
It might be usefull for newbies,
so I can share it. Let me know
if it is usefull from your perspective too.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic datasource register/unregister

Ludovic Orban
Administrator
Hi,

Good to hear everything is now clear for you.

Please share your hello world with JPA example, you should be able to attach it to your reply to this email.

Thanks,
Ludovic