Hello,

What sort of support does Hibernate have for dealing with a replicated database architecture where writes must be performed on the master while reads can take place on any slave? My company is developing a web application that is supposed to have mutliple instances of the application connected to a replicated database (most likely postgres w/slony) and I'm not clear on what the standard approach with Hibernate would be.

Is this just a matter of the application keeping two separate SessionFactory for reads ands writes, or can this be dealt with by clustering somehow?

Alternatively, is it simpler to use something like C-JDBC?

Thank you for any advice.

J.

Hi,

My first guess would be to use 2 ConnectionFactories, 2 cfg file, one for each database.

You first load all Hibernate Pojo from the first cfg file (behind or not of a "finder" business layer encapsulating the database choice) and you use a "writer busines layer" implementing the "save" and "saveAndUpdate" actions on each Hibernate Pojos to load the same Pojo from the second data base (2nd cfg) to update its values.

Etienne
Montreal

This is a problem much better solved at the JDBC level.

Gavin,

Thanks for your response.



That is the direction I'm leaning in. I'm not entirely comfortable with trying to use Sessions from two different Factories - while I think it would work most of the time the edge cases seem overly problematic.

I may just recommend that we use a replicated databse, but only as a hot backup. It's rapidly becoming clear that there is a good reason that master-master replication is a feature available mostly in commercial products - its not an easy problem to solve.

One last thing, do you have any warnings agaisnt using C-JDBC in conjunction with Hibernate? As far as I can tell a setup like this should work fine.

Thanks again.

J.

No, in fact I'd really like to hear about people who've had sucess combining Hibernate with C-JDBC because we have some big customers who are very interested in this kind of thing.