How your session factory is stored is totally dependent on your implementation. A pretty standard practice is to make the session factory available as a static property in a static class (make sure the session factory built once and only once!) so it only exists once per process. This would work the same under IIS as it would in any other environment (console app, winforms app, wpf app), but again that's just a standard practice, it doesn't mean that's how yours is handled so you really should figure that out first. I highly doubt your session factory is being rebuilt on every request because if it was your performance would be terrible if you are dealing with more than a handful of classes.
>From what I understand, the AppFabric provider you're using is a distributed cache provider so technically it shouldn't have a problem with being shared across multiple session factories since that's what it's supposed to do. Since it's built to be used concurrently you shouldn't run into any concurrency problems like the one your suggesting. The cache is what expires an entry, not nHibernate (although you can explicitly throw things out of the cache if your want, it's not done automatically), and since the cache is out-of- process all session factories have access to the same cache state at any given time anyway. Are all of your session factories accessing the same "domain"/ database? Because you can certainly run into problems if you are storing objects that belong to different databases in the same cache region. I don't really have an answer, other than to suggest that you download the cache provider source and step into it when the error occurs to see what's going on. It's also possible you're running into a bug in the provider. On Apr 18, 12:37 pm, Graham Bunce <[email protected]> wrote: > Hi, > > I'm using NHibernate L2 caching with AppFabric and using the AppFabric > caching provider written by Simon Taylor on GitHub. > > This works fine most of the time but every so often (after 5 minutes > or so in the test environment) I'll get a crash within the provider. > It's difficult to replicate in dev test but its along the lines of "an > expected element is not found in the cache". > > I think this is because of our architecture configuration and this > lead me to realise I don't fully understand how Session Factories are > stored in an IIS environment because "it just works". > > Our system is a web site running under IIS 7 or IIS 7.5 (error is the > same in both). This has its own App Pool. We also have 3 API web > service sites and these each have their own App Pool. We also have a > 4th element which is back-end server jobs running under a windows > service. > > I *think* that this means we actually have 5 session factories active > at one (4 for IIS app pools, and 1 for the Windows Service)..... but > I'm not actually sure how session factories are handed in IIS except > that you store the factory against the HTTP context. Wouldn't this > mean the factory is torn down after each request... except that this > doesn't appear to be what's happening....? > > I *think* what is happening is that since the L2 cache is shared out- > of-process, each session factory is using the same cache and one > factory may be expiring the cache item after an update, but the other > factories are not aware of this. They then try to access the element > in the cache which is no longer there and the NHibernate cache > provider falls over. > > Does this sound correct? if so, what would be the recommended why to > resolve this? One App pool across the entire application? > > Thanks -- 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.
