Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

request handling mechanism in a distributable web application

 
Kiaama Liames
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
can anyone explain the request handling mechanism in case of a distributable application ???
 
Phil Kurian
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rather general question, but here's a start.

A distributable application is an app (for the SCWCD purposes a web-app) which run on multiple servers. Usually the purpose for this is for load-balancing.

Lets say, the app is distributed across two servers A and B (it can be more than 2). In such a situation, the code, config files etc on both these servers would be identical.

When the user makes a request it passes through a load balancing server (physical or virtual) which directs the request to one of these servers.
Which server is chosen is at the discretion of the the load balancing server. This is completely transparent to the user.

What is important however is that whilst the user makes more requests, these requests will not necessarily be directed to the same server.

e.g. request1 -> server A
request2 -> server B
request3 -> server B
request4 -> server B
request5 -> server A
....
etc.

This has important implications for the developer of the web app. If it's a distributed app, the developer has to make sure that the application doesn't rely on servletContext attributes. This is because any attributes added to the servlet context are NOT migrated to the servlet context objects on the other web servers. Also, if the user is using a session, and the next request ends up going to a different server, the session migrates to the other server. This has implications for the objects bound to this session.

Hope that helps
 
Kiaama Liames
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks phil!!
In case of a distributable application each JVM has their own instance of ServletContext and ServletContext is not shared across applications and there is only one default context in distributed environment have you refered to the default context as a load balancing server (physical or virtual)

correct me if i am wrong
 
Phil Kurian
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In case of a distributable application each JVM has their own instance of ServletContext and ServletContext is not shared across applications and there is only one default context in distributed environment have you refered to the default context as a load balancing server (physical or virtual)


Yes, there each JVM has it's own context, and it is good practice to ensure that the context on each JVM is identical (i.e. same context-params, no attributes).
I'm not entirely familiar with the terminology of default context, but I know that a load balancing server is a completely different concept. Load balancing is a feature thrown in by Web App servers, and is usually vendor specific. On Websphere for instance receives all requests, and then redirects the request to the server with the least load. All of this is hidden from the user.

This stuff isn't really applicable to the exam. All you should really know is , the rules you need to follow if you make your app distributable. These rules basically boil down to ensuring your servlet context is consistent across all JVM, that objects bound to a session are serializable, and that you may want to use a HttpSessionActivationListener for informing when the session migrates from JVM to JVM
 
Kiaama Liames
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Phil
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic