Hi Bill
Yes, we have the same problem and I've been working on ways to improve
the situation. Unfortunately, I don't think there is an easy or simple
solution - a lot will depend upon your application.
As far as the database side of it goes it seems to me that much of it is
a question of making the 'live-update' a design requirement for any
upgrades. You have to make it possible for the changes to the database
to 'co-exist' and then update the live database independently of the
application. When the new tables are ready, deploy your new application
and (hopefully) go home smiling.
We tend to create DDL changes as SQL scripts - test them out on the
development systems and then run them on the live site. Some examples
make it easier to see what I mean.
A 'simple' change might be just adding an extra field with a static
default. Obviously easy - you just run the script, it adds the extra
field, the old app. doesn't have any knowledge of it. You make sure the
script correctly initializes the field. When the update app runs its there.
A more complex change is where a new field is required that may need to
be derived from existing data. Since this data may be changing on the
fly, you have to ensure consistency. The best way I've found for this is
to create an 'update' transaction in your ORM code (or whatever you are
using) that detects that the DDL state has changed and then runs an ACID
initialization of the new field.
Once again, the testing of this update is a key part of your release
testing strategy.
As for tomcat itself its rather going to depend whether you run
clustered or not.
One method that I've used on unclustered systems is to configure the new
system on a server instance on a different IP address on a system
fronted by httpd, set up some redirects in httpd and just, as it were,
'hup' from the old instance to the new instance.
This requires a DNS change, but any 'old' requests to the old server are
redirected to the new server. After about 48 hours you should be able to
shut down the old server.
However, we were able to catch an 'idle' period - you may not be able to
do that and you'd have to ensure that any sessions active on the old
server were correctly propagated to the new server.
I'd be interested to hear from people who have clustered solutions. Once
again I suspect there may be problems with trying to sustain sessions
across the upgrades.
Regards
Alan Chaney
Bill Davidson wrote:
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]
!DSPAM:48d172ca19921381456296!
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
