http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Maxim, actually my mistake this did not work, I had that setting configured already. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment21http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment21Thu, 20 Mar 2008 10:33:32 GMTThanks Maxim, that worked... http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment20http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment20Wed, 19 Mar 2008 21:09:17 GMTStuart, I had the same problem with SQLite in-memory and NHibernate 1.2: "no such table". After some research I have found that during transaction commit SQLite connection is closed therefore next queries could not find any tables. NHibernate doc (10.7. Connection Release Modes section) has interesting note: "As of NHibernate 1.2.0, if your application manages transactions through .NET APIs such as System.Transactions library, ConnectionReleaseMode.AfterTransaction may cause NHibernate to open and close several connections during one transaction, leading to unnecessary overhead and transaction promotion from local to distributed. Specifying ConnectionReleaseMode.OnClose will revert to the legacy behavior and prevent this problem from occuring." After addition key="hibernate.connection.release_mode" value="on_close" to the config file all my tests work with SQLite in memory with no problems. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment19http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment19Wed, 19 Mar 2008 11:17:35 GMTBTW The error with SqLite is interesting. It was failing with an error "no such table" which on doing some research is due to the fact that once you close the connection to the in memory db you cannot re-open a connection to it. This is disappointing if true...I changed the data source to point to a file on disk and this fixed the sqlite exception. Still no resolution on the cache miss though... http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment18http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment18Thu, 13 Mar 2008 17:11:04 GMTYes. Rhino.Security.Tests.AuthorizationServiceFixture.UseSecondLevelCacheForSecurityQuestions() fails. I simply replaced the CacheProvider with one of my own to enable me step into the code to see what was happening. But the test fails no matter which CacheProvider I use. I tested this against Sql2005 as SqlLite throws an ado exception (doesn't like the sql supplied) I am using a trunk build of nhibernate... http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment17http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment17Thu, 13 Mar 2008 11:29:47 GMTStuart, Can you produce a failing test case? http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment16http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment16Thu, 13 Mar 2008 11:02:44 GMTAfter some painfull debugging I have found that the second IsAllowed() method although producing identical sql and on from what I can see identical QueryKey objects, somehow the second call to IsAllowed() computes a different hashcode for the key to the one contained in the hashtable. I have had a look at the QueryKey implementation of GetHashCode override in nhibernate source and cannot fathom why the two would be different. Both calls are in different sessions/transactions and I am not using a custom provided connection. Am I missing something here? http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment15http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment15Thu, 13 Mar 2008 10:55:31 GMTI can't find it in the session factory. How did you debug the problem you had above? It seems difficult to get any visibility on cache hits... I am toying with the idea of writing a DebugHashTableCacheProvider to log the the internals... Any ideas? http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment14http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment14Tue, 11 Mar 2008 17:05:16 GMTWell, you can generally just access the cache object itself. I think it is accessible of the session factory. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment13http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment13Tue, 11 Mar 2008 16:27:14 GMTHi Oren, I am new to 2nd level caching in nhibernate but have come across this exact problem today where the 'UseSecondLevelCacheForSecurityQuestions' fixture in Rhino.Security.Tests is failing. The ficture is using the technique you outlined above. When debugging I can see from the output that the IsAllowed() call is calling into the db not the cache. Is there anyway to access the cache provider directly or is there something else I'm potentialy missing. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment12http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment12Tue, 11 Mar 2008 16:12:30 GMTYou generally create two session factories for it. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment11http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment11Sun, 27 Jan 2008 17:09:28 GMTThanks for quick shot. it's raising another question - how to handle multiple database scenario? (that's why we provide manualy connection to session). Since there is no easy way (or at least i dont know any) to handle multiple databases in one solution with one config file. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment10http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment10Sun, 27 Jan 2008 16:54:19 GMTYes, is you are doing it in this route. Which is rarely recommended. If you want a custom connection provider, you can implement the IConnectionProvider interface. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment9http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment9Sun, 27 Jan 2008 16:30:05 GMTsory for typos in last post. It should go like this: Since we have seesion with custom provided connection I can't use cache at all in Nhibernate? http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment8http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment8Sun, 27 Jan 2008 16:27:04 GMT>Another gotcha is that if you open a session with your own connection, it will not be able to put anything in the cache Lets consider some trival example: IDbConnection conn = myApp.GetOpenConnection(); ISession session = sessions.OpenSession(conn); Since we have seesion with cosutom provide connection I can use cache at all in Nhibernate? Or i got it wrong. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment7http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment7Sun, 27 Jan 2008 16:25:43 GMTPaul, Yes, you can. It is an cache implementation just like all the rest http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment6http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment6Fri, 25 Jan 2008 14:12:26 GMTI did not think you could use the querycache with memcache. Is it possible now to use memcache? http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment5http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment5Fri, 25 Jan 2008 12:30:43 GMTNo, they don't need that. This is because NHibernate doesn't save the entity in the cache. Doing so would open you to race conditions. NHibernate saves the entity data alone, which is usually composed of primitive data (that is what the DB can store, after all). In general, it is more efficient to hit a cache server, because those are very easily scalable to high degrees, and there is no I/O involved. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment4http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment4Thu, 24 Jan 2008 09:24:35 GMTIf that's true, objects need to serializable, are they not? As we're talking about multiple appdomains. I wonder what's more efficient: relying on the cache of the db server or transporting objects back/forth using serialization layers. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment3http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment3Thu, 24 Jan 2008 09:17:49 GMTNot really. The sync of the caches is left to the cache implementation. If we are talking about something like Memcached, we have no issue with syncing the cache, because all the machines in the farm see the same cache. Other cache implementations can send notifications, but that is outside the scope of what NHibernate does. http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment2http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment2Thu, 24 Jan 2008 08:58:25 GMT"The last cache is very important, since it ensures that the cache will not serve stale results." You talk about webfarms. What if a second server writes data to the db and the first server is reading data (but as it's cached, it will read from cache). The first server's session won't get a notify that a second server has updated the data in the db, meaning that when data is read by a thread on the first server, it will read stale data which IS already updated in the db. You always have stale data, however in this case, it's not said when the data in the first server's cache is updated with data from the db. I.o.w. the staleness can go on for a long time (as long as data is kept in the cache). http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment1http://ayende.com/3112/nhibernate-and-the-second-level-cache-tips#comment1Thu, 24 Jan 2008 08:54:25 GMT