Question regarding Session Migration

[Veena Pointi]

Hello Every one,
I want to understand session migration clearly.On page 257 of HFSJ it is very confusing to understand what happens to Httpsession objet when it is moved to different VM .

What exactly it means when it says "session is moved to VM2"? Does it mean
New session is created on VM2 and all the attribute values from VM1 are moved to VM2?
what happens to the session that is on VM1?It expires?
What happens to attributes that are bound?They are also moved ?

When they say everything is duplicated in the second server except HttpSession,what exactly this means?

Is there any detailed description on this? Please let me know if there is any reference on web to understand this clearly?

[Veena Pointi]

Never mind.I read the next page . I got confused when they said session is moved,but in UML diagram they showed sessionID as 343 on VM1 and sessionID as 128 on VM2....if they say it is moved,it should have same session ID right?

[Frits Walraven]

Hi Veena Pointi,

if they say it is moved,it should have same session ID right?

No, that is not required, actually this is what the specs (Servlet 3.0) say:

4.2 Scope of a ServletContext Interface
There is one instance object of the ServletContext interface associated with each Web application deployed into a container. In cases where the container is
distributed over many virtual machines, a Web application will have an instance of the ServletContext for each JVM.
7.3 Session Scope
HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the
same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.

In other words: the Session object created after migration contains the same information but it is another object that has another Session-Id (that is unique to the new JVM). It is not likely that the Session-Id of the migrated Session object is the same in both JVMs but it could be...(however the Session object is definitely a different one)


Regards,
Frits

[Stoian Azarov]

Hello Frits,

Frits Walraven wrote:

7.3 Session Scope
HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the
same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.

In other words: the Session object created after migration contains the same information but it is another object that has another Session-Id (that is unique to the new JVM). It is not likely that the Session-Id of the migrated Session object is the same in both JVMs but it could be...(however the Session object is definitely a different one)

I think that this section of the Servlet Specification is not related to session migration, am I missing something?
Maybe I am wrong but when I was reading this part of the specification I had the impression that they are talking about separate sessions in 2 different web applications on the same VM(in fact they might be clustered but this doesn't matter).
My personal interpretation of these sentences is: If the same user is using 2 different web applications, the container will create 2 separate session objects, but the cookie that is used might be the same.

Am I wrong? Should I revise this section of the specification again?
Regards

[Stoian Azarov]

Hi Veena,

Veena Pointi wrote:Never mind.I read the next page . I got confused when they said session is moved,but in UML diagram they showed sessionID as 343 on VM1 and sessionID as 128 on VM2....if they say it is moved,it should have same session ID right?

I think that the diagram on page 257 shows tha status of both VMs before the migration of the session object with id #343. So you have 2 session objects: #343 on VM1 and #128 on VM2 but these 2 objects are completely different, unrelated and probably represent different users.

[Frits Walraven]

Hi Stoian,

I think that this section of the Servlet Specification is not related to session migration, am I missing something?

Correct, it is not about session migration but about the scope of a Session.

What I was trying to point out is that a Session object is bound to the ServletContext it is created in, so even when you migratie a Session object in a distributed environment both the ServetContext and the Session objects are different. Likewise the Session Id will be different, but it could be the same in the unlikely event that both JVM's give out the same unique identifier.

I don't have the book with me but I thought that Veena assumed that those session identifiers would have the same value in case of a migration...


Regards,
Frits

[Stoian Azarov]

Hello Frits,
I see your point. Thanks for the clarification.

[Veena Pointi]

Hello Frits,

Thank you for explaining .I understand ServletContext and httpsession objects are completely different than the ones on VM1. I now know that when session is migrated from VM1 to VM2 session ID can be same or different . But I have following questions regarding this

1.In that case how will it identify if it is same user when request comes to VM2.

For ex first request is made to VM1 , Session is created
Second request is made to VM2,session is moved to VM2,but session id might be same or different.If it is different ,is this client treated as new client by VM2?

2.Also it is not clear to me what happens to attributes on VM1 that are bound to servletContext and session object,are they simply coppied to new objects on VM2?

3.On page 258 it is given "Everything else except session is replicated on each node while session is migrated." . Migration means session passivates on Vm1 and is activated on VM2. I didn't understand what does it mean by replication?

I am sorry if I am going out of exam topic . I wanted to understand session migration better as it is important while dealing real time applications.

Thanks,
Veena

[Frits Walraven]

1.In that case how will it identify if it is same user when request comes to VM2.
For ex first request is made to VM1 , Session is created
Second request is made to VM2,session is moved to VM2,but session id might be same or different.If it is different ,is this client treated as new client by VM2?

This will be up to the guys who make the container, as the Servlet 3.0 spec say "Migration of sessions will be handled by container-specific facilities" The container will move the session, so it will be able to know the old and new Session-Id of a particulair session.

2.Also it is not clear to me what happens to attributes on VM1 that are bound to servletContext and session object,are they simply coppied to new objects on VM2?

No, the objects will be serialized or in other words: the data will be flattened and reused in the new objects on the other JVM (have a look here: serialization)

3.On page 258 it is given "Everything else except session is replicated on each node while session is migrated." . Migration means session passivates on Vm1 and is activated on VM2. I didn't understand what does it mean by replication?

Replication means there are two instances of the web-application, ServletContext, Servlets and so on: one instance for each JVM. Logically the same, but not necessarily containing the same information: they are different objects. If one of your Servlets counts the number of requests it is handling you will definetely see a different number on both JVMs.

However the session containing valuable information about what the user has been doing in the web-application is only contained in one HttpSession object which is moved around depending on where the HttpRequest was sent by the load balancer.

Does this explanation help?

Regards,
Frits

[Veena Pointi]

It is helpful .It is very clear now.Thank you very much for explaining in detail.