Daniel Ansari’s blog Random software musings

February 12, 2010

NHibernate caching solution for web farms

Filed under: NHibernate,Open Source — Tags: , , , — admin @ 11:08 am

If your application uses NHibernate in a web farm, there is already a second-level cache provider that you ought to be familiar with: NHibernate.Caches.SysCache2, which supports expiration based on SQL table or command-based dependencies.  Whilst this is a decent solution, it does cause your whole cache region to be invalidated when data changes in the table.

It may be more ideal for you to invalidate the cache on a per-object basis, i.e., if one web server in the farm receives a request that causes a cached object to change, the portion of the application running on that server should be able to expire that object from the cache of all other servers within that farm.

A technique that I have used somewhat successfully is a shared disk cache invalidation mechanism called FileSysCache, similar to the “File Update Model” discussed in this MSDN library article.  Unlike the technique in that article, however, ours does not suffer from the issues arising from SQL Server trying to access the file system.  Our method creates a zero-length file on the shared disk, together with a CacheDependency to that file, for each cacheable object.  It deletes that file when the cache is invalidated for that object.  Thus, any other servers holding a cached copy of that object will have a CacheDependency on the same file, and their cached copies will expire.

This happens behind the scenes for you as an application developer.  NHibernate will call the relevant methods in the caching provider; all you need to know is that to expire the object across the web farm, you just need to evict it from the second level cache, using:


To configure FileSysCache, put the following into your web.config:

    <section name="filesyscache" type="NHibernate.Caches.FileSysCache.FileSysCacheSectionHandler, NHibernate.Caches.FileSysCache" />

and also:

  <filesyscache path="C:\Projects\NHibernate.Caches.FileSysCache.Tests\bin\Debug\Cache">
    <cache region="foo" expiration="500" priority="4" />

I meant to make this post a few years ago, so I hope the information here is still relevant, and I hope it’s better late than never.

The code, including unit tests, may be found here.

Adobe Flex Builder 3 problems in 64-bit Windows

Filed under: Adobe Flex,Open Source — Tags: , , , , — admin @ 12:54 am

Making the move to Windows 7 Professional 64 brought about a plethora of problems, some minor and some not so minor.

Fortunately most of the troubles were shared with other developers, and information is there to be found using our favourite search engines.

If you’re a Flex developer, like me, you might not have as much luck.  If you’ve downloaded the latest (stable) Flex SDK—3.4.1 at the time of this writing—it’s not possible to set up your “Installed Flex SDKs”, in order to set this SDK as the compiler default from the Preferences dialog.  That’s because of an issue on current x64 Windows where controls won’t get resized once the nesting hierarchy of windows exceeds a certain depth, which was referred to from the only useful information I could find about this specific issue.  It’s also not possible to set many preferences, as certain project properties show up as blank, and certain buttons are missing.  It’s absolutely abysmal that Adobe hasn’t remedied these issues; how does it expect developers to do any serious Flex development on 64 bit Windows that’s becoming mainstream?

Fortunately, there is a workaround, at least for the issues that affected me.  The solution lies in having a working copy of Flex Builder on a 32-bit Windows platform.  Flex stores these preferences in %USERPROFILE%\My Documents\Flex Builder 3\.metadata ( %USERPROFILE% is the environment variable with a typical value of “C:\Documents and Settings\{username}” on Windows XP, and “C:\Users\{username}” on Windows 7), and subfolders therein.

To configure your installed Flex SDKs, first unzip your Flex SDK to “C:\Program Files (x86)\Adobe\Flex Builder 3\sdks” (or wherever it is on your system); there is a file at the top level called flex-sdk-description.xml.  Open this up and make a note of the <name> element.  Next, open the file “%USERPROFILE%\My Documents\Flex Builder 3\.metadata\.plugins\org.eclipse.core.runtime\.settings\com.adobe.flexbuilder.project.prefs”.  This is where you’ll insert the setting for com.adobe.flexbuilder.project.flex_sdks, making sure you use the SDK name noted earlier.  My entire file looks like this (without the line breaks before “\r\n”):

#Wed Feb 10 17:49:32 EST 2010
com.adobe.flexbuilder.project.flex_sdks=<?xml version\="1.0" encoding\="UTF-8"?>\r\n<sdks>
\r\n<sdk location\="C\:/Program Files (x86)/Adobe/Flex Builder 3/sdks/3.0.0" name\="Flex 3"/>
\r\n<sdk defaultSDK\="true" location\="C\:/Program Files (x86)/Adobe/Flex Builder 3/sdks/3.4.1" name\="Flex 3.4"/>
\r\n<sdk location\="C\:/Program Files (x86)/Adobe/Flex Builder 3/sdks/2.0.1" name\="Flex 2.0.1 Hotfix 3"/>\r\n</sdks>\r\n

That fixes the first problem.

My other main problem was that I needed to debug the Flex application, but I was unable to add the launch configuration under Run/Debug Settings of the project properties—the New, Duplicate, Edit, and Delete buttons are missing and cannot be activated via the Windows shortcut keys.  If your project is called ProjectX, you’ll need to have a file called “%USERPROFILE%\My Documents\Flex Builder 3\.metadata\.plugins\org.eclipse.debug.core\.launches\ProjectX.launch”.  For me, the .launches folder wasn’t there, so I copied it from my 32-bit system.  You can create the .launches folder manually, though not from Windows Explorer (you may have to use the command line).  My file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<launchConfiguration type="com.adobe.flexbuilder.debug.launchConfigurationType.flash">
<stringAttribute key="com.adobe.flexbuilder.debug.ATTR_APPLICATION" value="src/ProjectX.mxml"/>
<stringAttribute key="com.adobe.flexbuilder.debug.ATTR_DEBUG_URL" value="http://localhost/abcde"/>
<stringAttribute key="com.adobe.flexbuilder.debug.ATTR_PROFILE_URL" value="C:\Projects\ProjectX\bin-debug\ProjectX.html"/>
<stringAttribute key="com.adobe.flexbuilder.debug.ATTR_PROJECT" value="ProjectX"/>
<stringAttribute key="com.adobe.flexbuilder.debug.ATTR_RUN_URL" value="C:\Projects\ProjectX\bin-debug\ProjectX.html"/>
<booleanAttribute key="com.adobe.flexbuilder.debug.ATTR_USE_DEFAULT_URLS" value="false"/>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
<listEntry value="/ProjectX"/>
<listEntry value="/ProjectX/src/ProjectX.mxml"/>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
<listEntry value="4"/>
<listEntry value="1"/>

For any other properties, you can search for a relevant string in the .metadata folder of your 32-bit machine, then copy or create the appropriate file in your 64-bit system.  It’s a pain, but at least you’ll be able to get your work done.

Powered by WordPress