Loading Database Properties later software, software

amy

Hi together,
I've got a difficult problem in my current project.
In my software, I want to set the hibernate database properties not directly. Rather I want to use the login dialog, to let the user choose between different databases, f.e. via a ComboBox.

But to the time I show the login form, all the hibernate settings are already set. Even in the onPreStartup method of my LifecyleAdvisor it is to late.

Does anyone have a good idea how to solve this problem?

Cheers fritzr

Are you using datasources? If so, you could use create your own datasource subclass that delivers connections based on the values set in your logindialog. For example, you could create a singleton class which is a holder for the values, and the datasource class creates connections based on values in that  singleton.

Or you could create a datasource from within your logindialog and put it as a bean in the springcontainer. This isn't the best method, since this implies changing your spring container after creation directly.

However, I think hibernate needs a connection at startup to validate your classes against the database, so you'll have to provide a default datasource.

Just my .02

Greetz,

Lieven

Tanks for your quick answer. It is not just the datasource, cause the hibernate properties are holding different other values, f.e. the dialect.

My solution, which actually makes me not very happy, is to add another application loader infront of my app, and which lets the user choose the database...

Isn't the dialect a property of a bean? If so, you could inject that bean into your logindialog and alter it's values from there... I know, not that nice a solution, but I reckon starting an application to start your's isn't the best either .

In my application, I use a datasourcefactory object defined in the context that I can configure based on the values obtained from the login dialog.

The key is then to make sure that the objects that depend on the datasource are not instantiated until after the login dialog has been confirmed. I fire an event to notify the parts of my app that depend on the datasource that it has been initialized, and can then be obtained from the context.

You can see how I have done it in WebScarab-NG:

The datasource factory in the context

The actual datasource factory

The quot;select databasequot; command

Hope this helps someone.

Rogan

And there lies the problem with my applications: I'm using JPA in combination with Hibernate. The persistence manager is loaded with my Spring bundle, and checks my scheme at startup.
I sort of hacked my solution by defaulting to a in-memory database (which is always valid), and assume my other databases are valid.


Originally Posted by LievenDocloAnd there lies the problem with my applications: I'm using JPA in combination with Hibernate. The persistence manager is loaded with my Spring bundle, and checks my scheme at startup.
I sort of hacked my solution by defaulting to a in-memory database (which is always valid), and assume my other databases are valid.

Like I said, the key is to make sure that the objects in the context that depend on the datasource are only referenced/instantiated AFTER the login dialog has been accepted. One thing I did was to specify quot;lazy-init=truequot; for beans that depended on the datasource, so that they would only be created AFTER the datasourcefactory was configured (and thus the datasource would also only be created on demand).

Hope this helps.


Originally Posted by rdawesLike I said, the key is to make sure that the objects in the context that depend on the datasource are only referenced/instantiated AFTER the login dialog has been accepted. One thing I did was to specify quot;lazy-init=truequot; for beans that depended on the datasource, so that they would only be created AFTER the datasourcefactory was configured (and thus the datasource would also only be created on demand).

Hope this helps.

That solution works if you have a 2-tiered application. In a client-server 3-tier application, that's a lot harder, since your server is started up independently from the clients. Even harder, multiple clients can connect to the same servertier, but for different databases.
To do that, you'll need to propagate some info with each client-request so the server can choose the right database. In my case in every request some data is put into a ThreadLocal, and my datasource class uses that ThreadLocal data to create a connection.