ASP.NET: Storing PersistenceManager instance in Session vs. Application

• Do not use the Default Persistence Manager in Web Applications.  This is because the Default Persistence Manager is defined in a static class, and therefore all sessions will share the Default Persistence Manager.  Using the Default Persistence Manager in Web Applications will cause unexpected behavior in your application
• Create a separate new instance of the Persistence Manager for each session
• Store the newly created Persistence Manager in Session for later use by the application session:
• Storing a Persistence Manager per session will ensure that the sessions will not interfere with one another's data

Paul,

I can't speak to the performance overhead, but I can speak a bit more on  why you have to do it this way.

I tend to think of this in terms of a standard ADO.NET dataset (which, after all, is what a Persistence Manager encapsulates).  In any web application, you're not going to want to have one ADO.NET data set that is shared among all website visitors.  Instead, you're going to instantiate, populate and persist one per user session.  The same holds true when you're using Persistence Managers.

So I don't know if I'd categorize a necessity as a performance issue.  You may be able to optimize things, but you can't get around it.

--Jeff



Edited by jeffdoolittle - 10-Oct-2007 at 11:49pm

Originally posted by jeffdoolittle I tend to think of this in terms of a standard ADO.NET dataset (which, after all, is what a Persistence Manage encapsulates).  In any web application, you're not going to want to have one ADO.NET data set that is shared among all website visitors.  Instead, you're going to instantiate, populate and persist one per user session.

Can you illustrate this a little further what you mean by this?  I can understand storing information that is specific to a user's session in Session state, but I'm not familiar with the model of caching a copy of all types of application data in each user's Session state.  Microsoft seems to have something else in mind.  The ASP.NET Cache API, for example, is indeed designed around the principle of sharing one instance of data among all visitors to increase both performance and scalability.  In most examples provided by Microsoft, you will see DataSets placed in the Cache for sharing data among many users.

Here's my analysis of what is considered the best practice for web applications (feel free to substitute "DataSet" for "cache"):  if I'm storing information on each active user of an application, I might want to have one instance of my User entity in a single shared cache, and query the cache for an instance as necessary. As an alternative, since a User entity is lightweight, it would probably be a candidate for placing in the Session. On the other hand, if I have a catalog of 10,000 products, I would certainly want to store no more than one instance of each of those entities in the cache.  If I had 1,000 users, each with their own copy of the 10,000 product catalog in their Session, then I have increased my memory usage 1,000-fold by storing 999 redundant copies of the data.   As the number of users grows, so does memory utilization, and my web application would soon come grinding to a halt under the weight of all that redundant data.

Granted, you could argue that sharing data increases concurrency issues, and data that the user is in the process of updating would probably best be stored in Session, but it seems to me that everything else is best shared in a shared cache of some sort.


Edited by pnschofield - 09-Oct-2007 at 11:03am

I think that Jeff has made the essential point here.

 

I tend to think of this in terms of a standard ADO.NET dataset (which, after all, is what a Persistence Manage encapsulates).  In any web application, you're not going to want to have one ADO.NET data set that is shared among all website visitors.  Instead, you're going to instantiate, populate and persist one per user session.

 

I understand your point that "it's considered a best practice to avoid using session state whenever possible", but we also know that a stateless application isn’t as interesting or as fun as one that carries a fair amount of state.

 

There is no requirement that a DevForce Web Application use a lot of memory for its PM Cache.  In fact, I would expect that a DevForce Web App would typically have a much smaller footprint than a comparable desktop smart client application.  If you’re really concerned about the scalability of your Web App, use less or even no caching.

 

One final point,  A PM is not something that you can dispose of as needed under low memory conditions and then rehydrate later when needed.  That is because a Persistence Manager is non-serializable.  For example, A Persistence Manager cannot be persisted to a SQL Server Database and then restored.

Edited by davidklitzke - 09-Oct-2007 at 3:56pm

David, I accept your point about session data being critical to web applications.  I'm just trying to distinguish user-specific session data from global application data.  It sounds like we're lumping everything that comes from the database into the session bucket when a good deal of it (such as the product catalog in my earlier example), is global application data and should be shared across all user sessions with caching whenever possible.

I'm hoping to see that IdeaBlade recognizes the difference and has a best practice for providing quick, cached access to global application data without creating a duplicate copy for each user.  I would think that global application data is where you would have the best odds of a cache hit, as multiple users have the opportunity to perform queries that have already been performed by other users.

Maybe it would help to think of it in terms of a use case involving Amazon.com customers.  Picture a large number of users visiting Amazon and searching for "Harry Potter".  From what I gather, the IdeaBlade model would have us cache an identical list of Harry Potter books for every single user for as long as their session persists (unless we clear their cache manually).  Every new search by a different user would perform the same query against the database and would store the same redundant data in the new user's session, using more system memory.  The only time we would see a cache hit would be if a user performed the same search twice.  Wouldn't it make more sense to have the results of a catalog search cached in a single shared location?  The first time the search is performed, the results are cached and every subsequent user's results are served from the cache.  Scalability and performance in one fell swoop!

Paul,

Edited by jeffdoolittle - 10-Oct-2007 at 11:49pm

Hi Paul,