Pitney Bowes MapXtreme - Manual (Page 112)

Chapter 6: Understanding State Management
State Management For Pooled Objects
MapXtreme v7.1 112 Developer Guide
Saving State for Pooled Applications
The pooled development model offers you two options for managing the state of your pooled
objects. You can use automatic state management, and have MapXtreme take care of the current
user state, or you can use manual state management and control the changes that must be saved
and restored for each user.
Automatic State Management
This scenario indicates that the state of the MapXtreme Session object will be saved automatically,
to the session mechanism defined in the Web.config (either StateServer or SQLServer). The
application programmer does not have to programmatically save any of the current user state
information, such as layers, thematics, open tables, or current zoom. The entire state of the
MapXtreme Session object will be saved.
This option saves system resources compared to the InProc model, since you do not have a
MapXtreme Session for each user and all users will share pooled MapXtreme Session objects. The
drawback is that the entire MapXtreme Session will be serialized to the currently defined state
mechanism. In general, the MapXtreme Session object retrieves all objects in its factories and
serializes them to the state mechanism. This includes all maps and their included layers, all open
table definitions, and any projections loaded. If the application is using automatic state management,
the MapXtreme Session object does not know about individual user’s state and stores all available
information. This includes layers that do not change from one user to another, which is the
background map. This can be a time consuming process and can cause this type of application to
perform more slowly than an InProc model. For information on serialization see
Serialization in
Chapter 8 on page 165 .
Manual State Management
This configuration means the MapXtreme Session instance will not automatically save any instance
data. It is up to the application programmer to include code in the application to save and restore the
state for each user. The MapXtreme Session object will not store any of its state to the currently
defined state mechanism.
This configuration provides for the greatest gain in performance and scalability. You are using
pooled MapXtreme Session instances that do not save any state, and these pooled objects are
being returned to the COM+ pool "dirty". By this we mean the pooled object has any modifications to
the map done by the current user and your application is responsible for cleaning up the state and
setting it correctly for the next user. You can choose to clean up at the beginning of your web
application request or the end.
Implementing a StateManager on page 122 .
The combination of using pooled MapXtreme Sessions and managing user state manually makes
this a complicated development model. You cannot tell which MapXtreme Session will be used for a
particular request; however, at the same time you need to satisfy the user’s request with a
MapXtreme Session that is specific to that user. For this reason, your application must be aware of
the beginning state of the pooled MapXtreme Session.