I have a decent understanding of the new Context object (or at least I think I do ), and I was wondering if this would be a practical use for it. For various reasons, including but not limited to security, I need to implement my own SessionStateProvider that targets an Oracle 9i database. The solutions is fairly straightforward--store all session objects in the database using derived session keys, fetch them back when needed, clean them out periodically (or on certain events), etc. In various situations, it may be possible for multiple users to be working on the same data in Session simultaneously (not necessarily modifying the data) and I wondered if using the Context object would make any sense in this scenario?

The context is an entity instance uniquing object, not an in-memory database. The problem with multi-user edits is that you need locking to get things properly scheduled. The Context object is meant for single-thread contexts, not for multi-thread contexts.

Session objects are single threaded as in: single user. This means that sharing data among threads / users is done through the Application object in asp.net, which does support locking.

So if multi-user is a requirement for the session management, your session object isn't really user state management, but application state management. Is this correct?

Otis wrote:

So if multi-user is a requirement for the session management, your session object isn't really user state management, but application state management. Is this correct?

That is partially correct--my intent is to implement a custom session state management scheme, with the same principle of providing temporary storage of session objects for each user, but as there may be situations where, for example, 3 users make a call to retrieve the same entity, I could save those 2 extra calls to the database if the first user already had an instance of that particular entity. Not a big deal, I was just curious. I think I will just stick to straight forward session management. Thanks

What you suggest is understandable (multiple users alter/use the same entity), but that would cause problems later on when the code acts like its alone (stateless, as with every webapp) but in fact alters an object which is also referenced in another thread. This requires per-entity locking (per field locking actually). I wouldn't recommend this.