I want to put together a mechanism to change the DataSource properties at runtime from within an app server, and I know I came across something relevant to this in the forum a while back, but it escapes me now.. what I think it suggested was a custom class to pick up the changes as they are made to the props file, trash any existing connections (which I presume can only be done if the connections are not active), and initialise, such that any new requests for Connections would use the new properties..

The relevant hibernate.properties entry would be required for hibernate.connection.provider_class..

Does anyone have any other suggestions, before I get stuck in??

Thx.

deployed, changing hibernate.properties wont take effect.
Thanks.

Actually, I managed to do this by putting in a custom ConnectionProvider (based on the DriverManagerConnectionProvider in Hibernate), naming that class in the hibernate.properties file so that it is found first time in (see fragment below).

The ConnectionProvider class checks to see whether the properties file that it originally used to load the properties has been updated. If it has, it reconfigures itself with the new changes. This can cause issues if there are connections open, so I beefed up the tracking of the open and free connections in the pool.

Because the check is made every time a getConnection() or closeConnection() is called, this is not ideal for a production environment, but it suits my particular need, which is to test against multiple DBMSs in a development environment.


hibernate.properties required setting:

Why don't you reconfigure the whole Hibernate and build a new SessionFactory ?

Thats a fair question.

Wouldn't rebuilding the SessionFactory be slow (in that it has to re-evaluate from scratch, while I simply change the attributes of new connections handed out from that point on, without having to rebuild the SessionFactory and all its associations, etc)?

In my config, the SessionFactory config takes about 10-15 seconds (ball park).. that seems a bit slow to have happen when the datasource properties change.

Another advantage of how I have done it is that if there are any connections handed "out" of the pool (ie, currently in use) when the datasource properties are determined to have changed (which is a definite possibility in a multi-user system, even in development), they are not affected by the reconfigure, and the stale connections are simply discarded when they get handed back in (they are in fact "VersionedConnection"s). This would not be the case with rebuilding the SessionFactory.. Exceptions would be thrown if there were Sessions (and connections) left open, wouldn't there??

Imagin you have a singleton keeping the SessionFactory (to make it simple)

Current threads do :



Your reloader session factory could do


Current threads, keep working with their session wo issue. Next time they will ask for a session, a new configured one will be given.

What about closing the old SessionFactory before we lose the reference to it? When does that happen??

I suppose we could track the number of Sessions being handed out from each SessionFactory, and when the SessionFactory is obsoleted by another, close it as soon as its last Session is closed (or disconnected, as the Session.close() seems optional).. that would be neat... but would require extending the Session implementation.

When we close the SessionFactory, we have to make sure there are no Sessions remaining open on it, or we'll get exceptions.

The time issue still applies as well.. my SessionFactory takes some time to initialise...