I get around my the same kinds of problems by keeping all the layers of the web app seperate so that i can swap them out one at a time and create a near seemless upgrade. The layers in my web apps are:
1 The web interface. 2. The application logic. (this may itself be several layers in itself if the app is complicated) 3. The database access layer. 4. The database. The key in your case is in the database access layer. The database access layer should be programmed to read either database format and write to the new one (filling in defaults/placeholders where necessary). All you need to do then is setup the structure for the new database on a new server (can use the server for testing while your at it). Drop in the new database backend. Do the rest of the data migration in the background safe in the knowledge that your webapp is still able to do whatever it needs with the old data and is already sending data to your new database aswell. The frontend can then be changed whenever (if at all). The key to any seemless upgrade is layers in the same way that redundency provides layers for server downtime. Hope what i said is useful. John5342 2008/9/17 Bill Davidson <[EMAIL PROTECTED]> > My company's main webapp is used around the world (Europe, North America, > Australia, etc.). > > We're using Tomcat as our app server and Oracle (10g) for our database. > > When we want to do an upgrade, that usually involves DDL changes to the > database as well as corresponding changes to the webapp which means we > have to make our users log out so we can shut down the app, update the > DDL and restart the updated webapp. The changes are interdependent. > It's all or nothing. > > This was not a big problem when we were just doing business in the U.S. > We'd do upgrades late at night when nobody (or hardly anyone) was using > the system. The problem now is that late at night here is middle of > the day in other places and downtime in the middle of the day is a real > problem. Our customers use our app to run parts of their business so > downtime in the middle of the day is very very bad. They understandably > don't like telling their customers: "I'd like to help you but I need to > wait for the Americans to upgrade their systems." > > I'm not sure how to deal with this. I've been trying to think of a way > to use multiple servers and multiple databases but that seems like a > synchronization nightmare. Losing data consistency is not an option. > > I'm sure that plenty of others on this list have had to deal with this > problem. Any suggestions? How have others dealt with it? > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
