Zero Downtime with Hibernate

Question

What changes to a database (MySQL in this case) does Hibernate survive (data, schema, ...)?

I ask this because of zero downtime with Hibernate.

Change database, split app servers into two clusters, redeploy the application on one of the clusters and switch application.

Thanks Stephan

Answer 1

I'll answer this from personal experience and not from any special insight into hibernate. So take this with a grain of salt. Also a bit of a vague question it seems, add comments where appropiate. :)

First of all, changing/adding/removing stuff to the schema that is not mapped in hibernate will never cause any problems. All hibernate really does is generate queries, since it translates a lot of stuff to SQL your app will simply continue working as long as those queries continue working. This means adding columns to a table or adding tables is not a problem, removing columns you've not mapped is not a problem either etc etc.

What's more problematic is changes to stuff that is mapped. Suppose you change a number(10,0) to a number(11,0), this will generally work. If you start doing stuff like changing a CHAR(1) field to a BIT field or something similar, you will need certain changes in your hibernate mappings, which will make an existing deployment fail. This is common sense. If you do have to make changes like this, executing the ALTER TABLE on a regular db server will probably lock the table anyway, so restarting the app is not your biggest problem.

Dealing with major schema changes under high availability is not something hibernate is meant to deal with directly. Hibernate assumes a traditional relational database where schema changes are often very expensive.

The three other problems you mention:

• changing data sources: probably requires an app restart
• splitting app server: if you mean what I think you mean, you can simply deploy on different app servers. If switchovers are requirement, use something in between your web app and the customer to handle them, i.e. an IP-level load balancer or similar.
• changing data: the normal problems with transactional databases and multiple writers apply. Hibernate might end up with an inconsistent view of the database. It might overwrite changes by other users and in some cases this might generate some exceptions, but you should be possible to anticipate and act on situations like these AFAICT.