5

This is related to a previous question I asked, regarding splitting a asp.net mvc web application into two apps - one public, and one admin. Both of them would be sharing the same database of course.

With two web apps I'll have two host applications and so two seperate Nihbernate session factories. My concern is that their seperate data caches will cause all sorts of problems.

While posting this, I looked at this question, which covers a similar problem (for a different reason). I really don't want to have to set up some kind of distributed cache just for a low use admin application.

How can this be resolved? Is separating the admin section into it's own application not possible with NHibernate without drastic measures?

Thanks.

Community
  • 1
  • 1
UpTheCreek
  • 31,444
  • 34
  • 152
  • 221
  • The solution depends on what you mean with "data caches". I think you mean one of the second level cache providers? – Paco Jan 04 '11 at 19:41

2 Answers2

1

We run this successfully although some discrepancy in the data is always a problem. However, since the 2nd level cache is configurable per site, you can disable as well as turn it down for specific cache areas on your manager.

The 2nd level cache will only be used for reading, since explicit updates will be flushed down and persisted directly.

If your concern is that content on the site will be "old" once modified, some sort of trigger will be needed to instruct the site to evict the cache. NHibernate will then evict all 2nd level cache for a specific entity type if I remember it correctly.

I think your problem with concurrency will be minimal if your site vs your admin will update different entities. For example in a webshop:

Site will create orders, modify customers etc but only read products, prices and categories

Admin will modify orders, products, prices and categories but only read customers

You can however instruct NHibernate to only update modified fields/properties on your objects for entities that you are concerned about concurrency issues with dynamic-update="true" on your mapping. This won't fully solve your problem, but minimize concurrency issues.

jishi
  • 24,126
  • 6
  • 49
  • 75
0

First, you should know that NHibernate doesn't enable second-level cache by default.

So, actually you don't even need any additional steps to complete to just not to use distributed cache. Just use your "Admin" ISessionFactory and don't enable any L2 cache for that.

It could be a sort of problem inside a single App/Factory but you already solved that problem by dividing them into 2 different physical apps.

tinonetic
  • 7,751
  • 11
  • 54
  • 79
Vasiliy R
  • 941
  • 8
  • 18
  • Thanks. But, why would it be a problem inside a single factory? Surely this problem comes about precisely because we're **not** using a single session factory? Also, regarding the 2nd level cache - even if it is only used on the public site, and left switched off on the admin site - this still could lead to inconstancy right? (you have potentially different data stored in two places, 1. In the cache, which the public app uses, and 2. in the DB, which the admin app accesses directly. – UpTheCreek Jan 09 '11 at 10:24
  • @UpTheCreek, right, I just wanted to say that you don't have to bend your head over caching/cache invalidation for "Admin-part". Sure, you can have the inconsistency, all sorts of concurrency problems but they'd be topic beyond caching. I mentioned that just because you told that you "really don't want to have to set up some kind of distributed cache just for a low use admin application". You should worry about stale data at your public part instead. – Vasiliy R Jan 09 '11 at 23:17
  • Also, imho, it is somewhat even better approach to have one and only one app and make that scalable. Sure, you'd face with all "cache-on-here-and-cache-off-there" problems but you will have more control and wouldn't have to think over "sync" between 2 apps. – Vasiliy R Jan 09 '11 at 23:23