Pitney Bowes MapXtreme - Manual (Page 111)

Chapter 6: Understanding State Management
State Management For Pooled Objects
MapXtreme v7.1 111 Developer Guide
This diagram represents an application that has a COM+ pool of two MapXtreme Session objects,
being accessed by three users (web clients). Whenever a client submits a request, the request will
be serviced by one of the two MapXtreme Session objects.
In this model, no client has its own dedicated MapXtreme Session. Instead, MapXtreme Session
objects are shared and re-used. The following sequence of events is possible:
1. Client1 might request a map zoomed in on Africa. This request might be handled using
SessionObj1.
2. Client3 might request a map zoomed in on Australia. This request might also be handled using
SessionObj1. In other words, each Session handles requests from multiple clients. No one client
"owns" the MapXtreme Session; they are all shared.
3. Client1 might submit a request to pan the map to show Europe. This request might be handled
using SessionObj2. In other words, there is no guarantee that every request submitted by a
particular client will be serviced by the same MapXtreme Session, or the same Map object.
Pros and Cons of Pooling
Pooling helps reduce the number of concurrent MapXtreme Session instances, and thereby reduces
the overhead of creating each object from scratch. When an object is needed, it is pulled from the
pool. When the object is not needed anymore, it is placed back into the pool to await the next
request. Pooling in MapXtreme means that multiple MapXtreme Session objects can already be
created and loaded with a background map and available when a web request is received.
Pooling helps you optimize the server's resources in the following ways:
• Improves overall response time for web applications by running several ASP.NET requests
concurrently.
• Conserves resources by reducing the number of concurrent MapXtreme Session instances.
• Maximizes CPU utilization by reducing the number of requests running at the same time (and
reducing thread context switching). This is particularly useful when requests are CPU intensive
(for example, Map image exports). The general recommendation is to have a pool size of 1-2
session instances per CPU.
However, a pooled application can make an application more complicated. MapXtreme Sessions
(and their maps) are shared and re-used; therefore, you need to take steps to ensure that each Map
is re-set to an appropriate state each time your application handles a client request.
For example, suppose a client requests a map of Germany. You cannot simply fetch a MapXtreme
Session from the pool and then use its Map to render an image, because there is no guarantee that
particular map is zoomed in on Germany. The Map that services the request must be set to an
appropriate, known state. As the application developer, you must manage the state of the object to
ensure that the object is in an appropriate state before you use it to service the current request.