Runtime manipulation of Hibernate mapping without restart

[ogeisser]

Hi.

We want to use Spring in combination with Hibernate and to utilize all the Hibernate support features of Spring (declarative transaction management, etc.).

So we have the usual setup for a web application with Spring and Hibernate:

• - Datasource definition
  - SessionFactory definition with injected Datasource reference
  - some Hibernate mappings
  - declarative TX proxy with reference to SessionFactory
  - ...

Nothing unusual here and everything works as expected.

But now we have the requirement that we need to expand/modify the Hibernate mappings during runtime. The administrator of the application can add columns to some tables and these columns should be mapped to a Hibernate "dynamic component".

Starting with the next request after the reconfiguration all requests should use the "new" mapping.

But the Hibernate SessionFactory is immutable. So you need to create a new SessionFactory with a modified mapping.

It would be easy to solve this with a kind of "restart".
Shutting down the spring container and starting again with a modied configuration. But this has the drawback that you must stop/wait for all running requests.


So what we want to achieve is something like the following:

mapping 1 -> SessionFactory1 (SF1)
  request1/thread 1 starts, uses SF1
  request2/thread 2 starts, uses SF1
  ...

-- modification of mapping
mapping 2 -> SessionFactory2 (SF2)

  all requests, which have started before, continue to use SF1
  new requests use SF2
  when all "old" requests have ended SF1 could be garbage collected

Has anyone solved this or has an idea how to solve this?

[Costin Leau]

IIRC, there were some discussions on the HB forums about that - HB 3 might have some support but I'm not sure - search/ask the forums; you might find something useful.
I would not recommend your approach because even though it can work in your scenario you'll have problems with the SessionFactory - even if you create a new SessionFactory for the new mapping, the old ones become invalid (the db model has changed) and once the requests hit the db through SF1 you'll get plenty of unrecoverable exceptions.
Try to solve the problem through HB or think of a different mapping - I have used the Serializable interface (stored classes directly in the db as blobs) for models that were simply too dynamic (view screens and the like). It doesn't help with relationships but it does work for simple, individual objects.
Another alternative would be to minimize the startup/shutdown of a restart - you can isolate the dynamic mapping inside different SessionFactories so when such a model changes you only have to shutdown one Factory but the rest still work. If you are using a serializated configuration the factory will start much faster (around 10x).Plus you don't have to restart the Spring container for this - you only have to create a new Factory using a new configuration.

Hope it helps.

P.S. If you find any links inside the HB forums please mentioned them. I for one, would be interested

[arif.mohammed1@wipro.com]

Hi,

Is this possible, if any one have solution for this please do post it.
I will be obliged for any examples.

Regards,
Arif.

[arif.mohammed1@wipro.com]

Hi Costin,

Can you please elobarate the second option "you can isolate the dynamic mapping inside different........."

My requirement is new Tables and classes get created while the system is running, this new tables and classes will not be used by existing threads but instead new threads.

My requirement is similar to ogeisser.

[ebusler@5thplateau.com]

Hi everyone, we have this great requirement as well for our Application.

Check out the Hibernate dynamic components. We are starting to test this solution with out products. We have extremely rich domain modeling, however I still think that this solution will work.

Here is a bit from the Hibernate website:
Link where I found it: http://www.hibernate.org/hib_docs/re...omponents.html

8.5. Dynamic components

You may even map a property of type Map:

<dynamic-component name="userAttributes">
<property name="foo" column="FOO" type="string"/>
<property name="bar" column="BAR" type="integer"/>
<many-to-one name="baz" class="Baz" column="BAZ_ID"/>
</dynamic-component>

The semantics of a <dynamic-component> mapping are identical to <component>. The advantage of this kind of mapping is the ability to determine the actual properties of the bean at deployment time, just by editing the mapping document. Runtime manipulation of the mapping document is also possible, using a DOM parser. Even better, you can access (and change) Hibernate's configuration-time metamodel via the Configuration object.


Checkout this link as well:

http://www.infoq.com/articles/hibernate-custom-fields


I will let you know if we get this working