Editor's Note: The ASP.NET2theMax newsletter is moving from Windevnet to Dr. Dobb's Journal. Beginning in June, the newsletter archives will be available on ddj.com. Your subscription to the newsletter will not be affected.
The session state can be stored in the ASP.NET worker process or in a separate process-either a Windows NT service (the state server) or SQL Server. When stored in the ASP.NET process, the session state, packed in a single collection object, is stored in the ASP.NET Cache. Each object is represented with a live instance and is managed through its reference. When the session state is stored outside the ASP.NET process, an extra step is required to read and write any contained objects. When ASP.NET begins processing a request, the session state is retrieved from the external process and loaded into the ASP.NET worker process. All the entries are copied into a dictionary, which is then attached to the HTTP context of the request. This dictionary is an instance of the HttpSessionState class and is programmatically accessible through the well-known Session keyword.
At the end of the request, the session state is flushed back to the storage process. Both in reading and in writing, therefore, the session state must be transmitted in and out of the ASP.NET process. In .NET, interprocess communication is implemented through the .NET Remoting API and object serialization. Let's see what happens when you place a DataSet object into the ASP.NET Session object.
As long as the session state is configured to work in-process, using the DataSet presents no special issues. However, if you configure the ASP.NET application to support out-of-process session state, the DataSet may become a significant bottleneck. Once stored in the session state, the DataSet is serialized and deserialized for each request served. ASP.NET uses the BinaryFormatter class to serialize and deserialize complex objects like the DataSet. The DataSet class supports serialization through the ISerializable interface, meaning that the class controls its serialization process entirely. In particular, the DataSet receives an empty buffer and fills it with an XML representation of its contents. The current snapshot of data, changes entered since last commit, and pending errors on the rows are written to the XML representation of the DataSet state. This XML schema is known as the Diffgram and is a pretty large and verbose schema. More importantly, the Diffgram is not a binary sequence of bytes and doesn't generate a compact output once written to a binary stream. As a result, when serialized, the DataSet takes up even more memory than required by a live instance. Large DataSets made of several tables and relationships can easily reach the considerable size of a few megabytes. If stored to the session state, with an out-of-process session state, the DataSet represents a significant overhead for your web application.
For this reason, you should avoid placing a DataSet into Session if you're going to implement an out-of-process session state. This situation is by design and will probably be fixed in the next version of the .NET Framework-the one shipping with Visual Studio .NET 2005. In the meantime, here is a possible workaround.
You derive your own class from DataSet, implement the ISerializable interface, and opt for a different serialization algorithm. In doing so, the simplest thing you can do is to just compress the default XML script generated by the base class.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
