Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4BDEA798.3000702@ice-sa.com>
Date: Mon, 03 May 2010 12:38:16 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Updating webapps classes
References: <27575732.2.1272870689851.JavaMail.gbulfon@pgbulfon>
In-Reply-To: <27575732.2.1272870689851.JavaMail.gbulfon@pgbulfon>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gabriele Bulfon wrote:
> Hi, thanx for the interesting solution.
> Anyway, not always possible to run 2 tomcat instances because of memory requirements.
> Do you see any different solution with 1 tomcat only (or tomcat + apache)?

Gabriele,
I think Peter gave you the only appropriate general answer.

You could imagine a scheme whereby
- you have under Tomcat 2 versions of your webapp (say /webappA and 
/webappB), of which only one is the active one at any particular time
- your users access the application by a URL like /XYZ/..
- the front-end Apache, by using something like mod_rewrite, would 
rewrite such URLs to either /webappA or /webappB, before forwarding them 
to Tomcat. Say that for the moment the active one is webappA, and the 
Apache front-end rewrites /XYZ to /webappA.
- then you update webappB
- then you change the Apache rewrite rule to rewrite /XYZ to /webappB, 
and reload Apache (not restart, reload)
- then you can update webappA
...
BUT, how your Tomcat applications and the ongoing user sessions in them 
will react to this, only you can tell, knowing your application and what 
kind of change you make from one version to the next.
Clearly, if a change involves changing the content of what is stored in 
a session, or the forms you are sending to the browsers (*), you would 
be in trouble.  My knowledge of Java and Tomcat is too limited to know 
what other kind of trouble you may be in, but I can imagine it may be 
plenty.

It may work, if every HTTP request to Tomcat is really independent of 
any previous one, and you do not use sessions.

Peter's solution is the real solid one.  Memory requirements can be 
solved nowadays for very little money.  The time you would spend 
designing and debugging a scheme like the above would be many times more 
expensive.


(*) example :
- webappA sends a form to a browser, with input fields a,b,c,d.
- you update webappB, and now the form has fields a,b,c,d,e, and webappB 
expects that
- now you switch webappB for webappA
- then the user submits the form, still with fields a,b,c,d.  But this 
submit goes to webappB now.
Does webappB survive ?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org