using new database properties

[valerien]

Hi,

I'm using SmartClient Version: v8.3p_2013-05-12/PowerEdition Deployment (built 2013-05-12) with PostgreSQL 9.2.2, Firefox 23.0.1, and Tomcat 7.0.33.

I had an old thread where I asked about updating server.properties. (http://forums.smartclient.com/showthread.php?t=26787). I've taken the advice in that thread. I keep my properties somewhere else, load them after the Init servlet and use the Config class to update the global properties. All that seems fine.

The parameters I want to change are the database connection parameters from server.properties like sql.PostgreSQL.driver.serverName. I also need to change these parameters after the application has been running and the Config class works fine for that. But, of course, the database connection mechanisms have already been set up and the new property changes are not honored on the fly.

I need the database support to start using the new properties. I should be able to do this by reinitializing/reseting/recreating the database connection/pooling support components. It should be possible because this is like the adminConsole's behavior. (I would just use the adminConsole, but the users want a simpler interface.) All the database support I typically use is wrapped by SmartGWT functionality. What are the objects I need and how do I get them?

I could also just be doing this wrong. Is there some better way to have the running server start using the new database properties?

Thanks
Kevin

[Isomorphic]

Imagine you had a button that could shut down all connections - your users could be in the midst of anything at that point, and encounter all kinds of errors. Killing those connections would produce a similar experience to just restarting the application server with new settings.

What you could do is create a new database config on the fly, and use a DynamicDataSource generator so that any newly requested DataSources set their dbName attribute to use this new config (see this post for sample code).

It's up to you to figure out the timing of how you switch users over to the new DB settings. You could, for example, do it when they next log in.

[valerien]

Hi Isomorphic,

Thank you very much for the reply.

You describe the perfect button for me, but you describe it as a bad thing. :)

The post you referenced has great stuff. I had skimmed that post before but didn't realize its relevance.

DataSource.addDynamicDSGenerator is server side. Is it specific to each user? Is that what you meant by switching users over? That the DynamicDSGenerator will need to be added for each user individually and after it is added all that user's future datasources will come from the new DynamicDSGenerator?

I expect this database parameter change function to be used rarely. Despite it being harsh, I could possibly accept restarting the application server with new settings, but I'm not aware of any way to do that programmatically. Did I miss something?

Thanks,
Kevin

[Isomorphic]

If you want to just restart the server, your server probably has some kind of admin console that you can access remotely to do so.

No, DynamicDSGenerators are not per-user, and you do not need to register more than one per user. But you could have the behavior depend on whoever is the current user.

Sounds like you probably want to skip all this and just find the admin console for your server.

[valerien]

Thanks Isomorphic. I think I understand. I can have one DynamicDSGenerator which is used by all users. A particular user will not use that DynamicDSGenerator until after it is registered for them with DataSource.addDynamicDSGenerator. After registration any new dataSources will use the DynamicDSGenerator. Please correct me if I wrong.

This seems very different from how the adminConsole works. Does it use a different mechanism? Is that mechanism available or is it internal?

Thanks,
Kevin

[Isomorphic]

Right, if you register a DynamicDSGenerator with no prefix or regex (see JavaDoc) it is used for all DataSources.

The Admin Console uses an internal mechanism roughly equivalent to restarting the application server, that is, not appropriate or supported for use in a live system.