-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peng,
Peng Tuck Kwok wrote:
> There's a lot of good suggestions here, maybe you could also justify
> maintaining a separate instance for the American customers. That would at
> least allow at a minimum to roll out changes specific for them, conform to
There's a lot of good suggestions here, maybe you could also justify
maintaining a separate instance for the American customers. That would at
least allow at a minimum to roll out changes specific for them, conform to
their maintenance time :P. Yes I do realize it would be a replication of
code in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan,
Alan Chaney wrote:
> 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
ial nature and Sender does not
endorse distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> Date: Wed, 17 Sep 2008 16:08:19 -0700
> From: [EMAIL PROTECTED]
> To: users@tomcat.apache.org
> Subjec
>I think it will be useful when we get to the point of redesigning the app
>from scratch. It's a bit tough to replace the data access layer of a large
>complex app that's been around for a long time though.
It is indeed difficult to change a long standing app but in the long run its
a better appr
John5342 wrote:
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 lay
u have any dependency in the application on how the ID if formatted.
If that's your only concern, you're doing good so far!
Paul McGurn
-Original Message-
From: Bill Davidson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 17, 2008 6:45 PM
To: Tomcat Users List
Subject: Re: Serve
Paul McGurn wrote:
Segregate, geographically, your customer base's target infrastructure. The way they do this is by
tying their customers to a specific "cluster" of their cloud, and then everything that
customer does in the application is tied back to that "cluster". The layer of redundancy
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
t
I think the ideal approach here (potentially) is segregating your customer
base. Here's an idea directly from how Salesforce.com does it.
Segregate, geographically, your customer base's target infrastructure. The way
they do this is by tying their customers to a specific "cluster" of their
cl
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 mak
11 matches
Mail list logo
