Hi all,
Sorry abt hi-jacking this thread...but it is a related topic:
I was trying to configure second level caching for my NHibernate
application.
The component that accesses the database in the application runs as a
Windows service, and there are other components which include a few
WCF services, a client GUI and so on.
Anyway, because the application is a long-running server, and I'd like
to improve its performance and scalability, I was looking to improve
data access among other things.
So, I came across 2nd level caching providers, and it looks like
everything available for NHibernate seems to be focussed on the web-
based application scenario. SysCache, SysCache2 - for example.
The Hashtable provider is 'not recommended for production use' says
the documentation - why is that?
Also, I tried the Bamboo Prevalence provider. A simple unit test that
looped through and called a 'GetUsers' method a bunch of times was
very *slow* when I turned on the bamboo cache. I use dotTrace to
profile the unit test and see what was happening, and saw the
following stats (I've changed the namespaces for my project).
I also ran the same test a few times with the Hashtable cache provider
and it is quicker than the scenario without any 2nd level cache.
So, the question is:
Can I just use the Hashtable provider? Why is not recommended by the
docs?
Is there an alternative to Bamboo which performs atleast as good as
the Hashtable one, and does not depend on ASP.NET?
Any ideas / suggestions / pointers will be greatly appreciated.
Krishna
DotTracer profiling stats below with Bamboo prevalence based 2nd level
NHib cache:
-----------------------------------------------------------------------------------------------------------------------------
20.58 % GetUsers - 11496 ms - 50 calls -
xxxx.xxxx.Manager.Persistence.SecurityDao.GetUsers()
...
20.00 % InitializeEntity - 11174 ms - 300 calls -
NHibernate.Engine.TwoPhaseLoad.InitializeEntity(Object, Boolean,
ISessionImplementor, PreLoadEvent, PostLoadEvent)
11.10 % ResolveIdentifier - 6203 ms - 150 calls -
NHibernate.Type.CollectionType.ResolveIdentifier(Object,
ISessionImplementor, Object)
11.10 % ResolveKey - 6203 ms - 150 calls -
NHibernate.Type.CollectionType.ResolveKey(Object, ISessionImplementor,
Object)
11.10 % GetCollection - 6202 ms - 150 calls -
NHibernate.Type.CollectionType.GetCollection(Object,
ISessionImplementor, Object)
11.08 % InitializeCollection - 6193 ms - 150 calls -
NHibernate.Impl.SessionImpl.InitializeCollection(IPersistentCollection,
Boolean)
11.08 % OnInitializeCollection - 6192 ms - 150 calls -
NHibernate.Event.Default.DefaultInitializeCollectionEventListener.OnInitializeCollection(InitializeCollectionEvent)
11.08 % InitializeCollectionFromCache - 6189 ms - 150
calls -
NHibernate.Event.Default.DefaultInitializeCollectionEventListener.InitializeCollectionFromCache(Object,
ICollectionPersister, IPersistentCollection, ISessionImplementor)
6.85 % InitializeFromCache - 3826 ms - 150 calls -
NHibernate.Collection.PersistentArrayHolder.InitializeFromCache(ICollectionPersister,
Object, Object)
4.22 % Get - 2358 ms - 150 calls -
NHibernate.Cache.NonstrictReadWriteCache.Get(CacheKey, Int64)
8.84 % Put - 4941 ms - 300 calls -
NHibernate.Cache.NonstrictReadWriteCache.Put(CacheKey, Object, Int64,
Object, IComparer, Boolean)
0.01 % ResolveIdentifier - 7 ms - 150 calls -
NHibernate.Type.EntityType.ResolveIdentifier(Object,
ISessionImplementor, Object)
On Oct 5, 1:39 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> Sounds like you want to use cache regions instead.
>
>
>
> On Sun, Oct 5, 2008 at 5:37 AM, jason.hill <[EMAIL PROTECTED]> wrote:
>
> > My requirement is to handle the case of a batch process updating
> > domain data and the need to subsequently ensure that interative users
> > have the most recent data. The batch process sends an email to users
> > upon completion informing them of updates to their account data. This
> > email often prompts users to log back in and check out the updates so
> > they must have a current view of the data.
>
> > So, it feels appropriate to cache this data to gain the performance
> > improvement for interactive users and then to just clear them from the
> > cache at the end of the batch process. I have set it up to Evict all
> > the classes, subclasses and collections that are touched by the batch
> > process and it seems to be working perfectly.
>
> > Fabio: would you see this as being an appropriate use of Evict?
>
> > Jason
>
> > On Oct 5, 5:03 am, "Fabio Maulo" <[EMAIL PROTECTED]> wrote:
> > > When you have so much evict you must ask you:1) my Cache is well
> > configured
> > > ? (regions, mode, expiration...)
> > > 2) do I really need that entity in the Cache ?
>
> > > When you have so much evict for Session-Cache (aka first-level-cache),
> > you
> > > must ask you:
> > > 1) do I manage the session as this use-case need ?
> > > 2) do I need a stateLessSession ?
>
> > > The use of Evict is acceptable in some, few, very special cases and an
> > > extensive use of it is a symptom of some other problem.
>
> > > 2008/10/4 Jesse <[EMAIL PROTECTED]>
>
> > > > I agree with you Fabio. Evict doesnt work quite as you would expect
> > > > it to from a user standpoint though. For example, I have a rental
> > > > queue that can be cached with a line items collection that is also
> > > > cached. If I evict the RentalQueue, the cached collection is left in
> > > > cache. If I evict the collection then each line item is still cached.
> > > > So to evict everything related to the rental queue, I must first evict
> > > > each line item, then the collection, then finally the queue. From the
> > > > developers point of view this a pain.
>
> > > > You may ask, why would i want to do something like this. Well each
> > > > line item has a version column and so does the rental queue itself. If
> > > > I get a stale object exception when updating one of the line items I
> > > > just want to evict the whole rental queue from the cache.
>
> > > > Seems like we should be able to make this process a little easier or
> > > > more intuitive.
>
> > > > Jesse
>
> > > > On Oct 4, 5:13 am, "Fabio Maulo" <[EMAIL PROTECTED]> wrote:
> > > > > hmmmm.... too much extensive use of Evict...
>
> > > > > 2008/10/3 jason.hill <[EMAIL PROTECTED]>
>
> > > > > > Excellent...thanks again.
>
> > > > > > Do I need to evict the association class as well as the collection,
> > > > > > e.g.
>
> > > > > > Evict(Parent)
> > > > > > EvictCollection("Parent.Children")
> > > > > > Evict(Child)
>
> > > > > > Also, if I evict an abstract base class, will all subclasses be
> > > > > > evicted automatically or do I have to evict each one separately,
> > e.g.
>
> > > > > > Evict(Parent)
> > > > > > Evict(SuperParent)
> > > > > > Evict(SuperDuperParent)
>
> > > > > > On Oct 4, 8:32 am, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> > > > > > > no, for that you need EvictCollection
>
> > > > > > > On Sat, Oct 4, 2008 at 1:26 AM, jason.hill <
> > [EMAIL PROTECTED]>
> > > > > > wrote:
>
> > > > > > > > Thanks.
>
> > > > > > > > Just to confirm...this will also evict associations where I
> > have
> > > > > > > > cascade="all" or "all-delete-orphan"...right?
>
> > > > > > > > On Oct 3, 6:32 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> > > > > > > > > sessionFactory.Evict()
>
> > > > > > > > > On Fri, Oct 3, 2008 at 7:55 AM, jason.hill <
> > > > [EMAIL PROTECTED]>
> > > > > > > > wrote:
>
> > > > > > > > > > Hi,
>
> > > > > > > > > > I have a web app with the second level cache turned on. I
> > then
> > > > have
> > > > > > a
> > > > > > > > > > batch job that runs as part of task scheduler
> > intermittently
> > > > > > > > > > throughout the day to process some stuff against the
> > domain.
>
> > > > > > > > > > At the end of the batch job, I want to trigger a clearing
> > of
> > > > the
> > > > > > > > > > second level cache in the web app so that interactive users
> > > > will
> > > > > > > > > > always be looking at the current data from the DB. What is
> > the
> > > > best
> > > > > > > > > > way to do this?
>
> > > > > > > > > > I know I can recycle the app pool but then it can disrupt
> > users
> > > > > > that
> > > > > > > > > > are already logged in, forcing them to login again so that
> > is
> > > > not
> > > > > > an
> > > > > > > > > > option. I am assuming that I will need to programatically
> > > > submit a
> > > > > > web
> > > > > > > > > > request against the application to clear the cache
> > manually. Is
> > > > > > that
> > > > > > > > > > right? How do you manually clear the cache though?
>
> > > > > > > > > > Thanks,
>
> > > > > > > > > > Jason- Hide quoted text -
>
> > > > > > > > > - Show quoted text -- Hide quoted text -
>
> > > > > > > - Show quoted text -
>
> > > > > --
> > > > > Fabio Maulo
>
> > > --
> > > Fabio Maulo- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
