I could imagine scenarios where each of the alternative behaviours is
acceptable. Allowing existing sessions to continue while preventing new
sessions from starting is less disruptive to clients and would allow a
server to be 'quiesced' once the number of existing sessions had decreased
to zero. On the other hand, there may be a need to break existing sessions
to perform some kind of urgent upgrade. Perhaps the former behaviour should
be the default and the other should be available as an option (via a
parameter).

Glyn


                                                                                       
                                              
                      Russell                                                          
                                              
                      Butek/Austin/IBM@        To:       [EMAIL PROTECTED]       
                                              
                      IBMUS                    cc:                                     
                                              
                                               Subject:  Re: deploy problem. 
<parameter name="scope" value="session"/> would         
                      11/03/02 15:26            notwork.                               
                                              
                      Please respond to                                                
                                              
                      axis-dev                                                         
                                              
                                                                                       
                                              
                                                                                       
                                              



OK, folks, what do y'all think?  Since the session info ultimately resides
in HTTPTransport, even though there are multiple services/stubs/Call
objects, the cookie info is preserved.  So if you turn on sessions, turn
them off, and turn them back on again, you're still in the original
session.  Is this the proper behavior?  Or should we get a new session each
time we call setMaintainSession?

Russell Butek
[EMAIL PROTECTED]


Akira Hirose <[EMAIL PROTECTED]> on 03/10/2002 07:49:13 PM

Please respond to [EMAIL PROTECTED]

To:    [EMAIL PROTECTED]
cc:
Subject:    Re: deploy problem. <parameter name="scope" value="session"/>
       would  notwork.



Mr. Russell Butek,

Thank you for your prompt reply.

Although the behavior is bit different from I expected, but it worked fine.
A new client program, and its result are attached below.


Russell Butek wrote:
>
> It isn't sufficient to tell the server that the service is session scope.
> The client must be aware of it as well.
>
> locator.setMaintainSession(true);
>
> Russell Butek
> [EMAIL PROTECTED]
>

The output of my test program. Third call block starts with 3, though I
expected 1. So, it must be the same session of the first call block.

 test start
 (1): 1
 (2): 2
 test end
 test start
 (1): 1
 (2): 1
 test end
 test start
 (1): 3
 (2): 4
 test end
 test start
 (1): 5
 (2): 6
 test end


/* Client.java */

package localhost;


public class Test1 {

 private static void test(boolean maintainSession) {
  try {
   int i;
   LifeSpanTestServiceLocator  locator = new LifeSpanTestServiceLocator();
   locator.setMaintainSession(maintainSession);
   LifeSpanTest svc = locator.getLifeSpanTest();
   System.out.println("test start");
   System.out.println("(1): "+ String.valueOf(svc.getNext()) );
   System.out.println("(2): "+ String.valueOf(svc.getNext()) );
   System.out.println("test end");
  } catch ( Exception e ) {
   System.err.print(e);
  }
 }

 public static void main(String [] args) throws Exception {
  test(true);
  test(false);
  test(true);
  test(true);
 }
}



/* akira.hirose */






Reply via email to