-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 7 posts ] 
Author Message
 Post subject: Guidance on Persistent Entity and HttpSessionState
PostPosted: Mon Aug 13, 2007 2:31 pm 
Senior
Senior

Joined: Sat Sep 10, 2005 3:46 pm
Posts: 178
I have a persistent entity, Account, which i want to store in asp.net session state so that I dont have to retrieve it on every request.

I was just wondering if some others could give me some guidance on storing a persistent entity in http session state. I'm sure there are issues such as attaching and detaching the entity from the Nhibernate session. Also I think there might be issues with entity associations and how they are stored in Asp.net session as well. Basically Im just looking for any help as I go down this development path and hopefully we can get a good conversation going here to help others in the future.

Thanks,
Jesse


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 13, 2007 4:47 pm 
Newbie

Joined: Sun Aug 12, 2007 2:34 pm
Posts: 8
Location: Geneva, IL USA
Won't NHibernate's caching abilities be better suited than the issues you will get by putting this entity in a Session object? I'm no expert NHib's caching so maybe someone can chime in on that.
I avoid ASP.NET's Session whereever possible....no matter how much MS says it's gotten better over the past few revisions.

LH


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 13, 2007 5:29 pm 
Expert
Expert

Joined: Tue Aug 23, 2005 5:52 am
Posts: 335
I'm with LordHits on this one - you can store the Id in the session state and then use it to reload the object using NHibernate. If you have NHibernate 2nd level cache enabled you still won't hit the database but you'll get back an object that will be connected to a Session and will support lazy loading of it's children.

Also, if the object is changed in another thread or process that's sharing the same 2nd level cache it's possible to invalidate the object so if you *do* need the object to be up to date NHibernate can make the choice to go back to the database for the updated version.

Cheers,

Symon.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 13, 2007 10:14 pm 
Senior
Senior

Joined: Sat Sep 10, 2005 3:46 pm
Posts: 178
Ive never been one for using session state either but on this particular project I think session state will be much more efficient than NHibernate cache. The data in question is read/write data. Its much more read than write, but its not static by any means. And I've never been much of a fan of putting data that can change often into the NHibernate cache. Also the Asp.Net session will perform much better then the NHiebrnate cache since the NHibernate cache creates locks for all cache reads and puts and much more so for Read/Write cache. Im much more of an expert on Nhibernate caching than I am on Session state so that is why i have some concerns about using the caching for this type of data.

Also, the current cache providers do not support sliding expiration. When I wrote SysCache2 for SqlDependencies I didnt think to throw sliding expiration in there. I guess it wouldnt be hard to add, but that was another reason i was leaning toward asp.net session.

Why is that you guys look at asp.net session so negatively?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 13, 2007 10:15 pm 
Senior
Senior

Joined: Sat Sep 10, 2005 3:46 pm
Posts: 178
duplicate


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 14, 2007 4:12 am 
Expert
Expert

Joined: Tue Aug 23, 2005 5:52 am
Posts: 335
It's not that we're negative per se but we've tried the using session state in the past with regards to primarily read only data and it's much easier to use the NHibernate cache than to worry about the lazy loading problems that come up using http session state. Certainly we don't have a problem with the performance of using the NHibernate cache in our scenario.

If you're using read/write then you're in a whole different boat...race you to the finish line! :)

Cheers,

Symon.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 14, 2007 5:41 am 
Beginner
Beginner

Joined: Wed Oct 04, 2006 8:57 am
Posts: 25
I am not sure exactly what you are trying to achieve but this might be of interest to people anyway.

I created this class to store objects in session via a key so that you can work on an object over mutliple page requests without having to persist the changes.

Code:
    public static class SessionContext<T> where T : class
    {
        static SessionContext()
        {
        }

        private static Dictionary<Guid, T> fakeSession = new Dictionary<Guid,T>();


        public static T GetItem(Guid key)
        {
            T current = null;
            if (HttpContext.Current == null)
            {
                current = fakeSession[key];
            }
            else
            {
                current = (T)HttpContext.Current.Session[key.ToString()];
            }

            return current;
        }

        public static void SetItem(T item, Guid key)
        {
            if (HttpContext.Current == null)
            {
                fakeSession.Remove(key);
                fakeSession.Add(key, item);
            }
            else
            {
                HttpContext.Current.Session[key.ToString()] = item;
            }
        }
    }


So you can call:

Code:
SessionContext<MyClass>.SetItem(theObject, key)

and on subsequent requests (I pass the key around in the query string)
Code:
SessionContext<MyClass>.GetItem(key)


You need to make sure that the object is fully loaded before doing this (or at least don't try an access lazy loading properties) and also evict it from the NHibernate session.

Then when you are ready to save it just save it as normal.
I haven't used this with any sort of concurrency considerations, I imagine there will be some issues to resolve there..

Oh, for the record I am pretty anti session, but it does make this scenario quite easy.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 7 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.