Telerik OpenAccess ORM in Web Applications

When using Telerik OpenAccess ORM in web environments there are a few things to consider depending on the settings of the IIS application pool. The IIS by default uses the overlapped recycling mechanism (see this link) which means that the OpenAccess configuration can be used by two different processes in parallel, potentially leading to problems in different areas such as logging and the second level cache.

Logging considerations

When logging to a file it is recommended to add the process' thread id to the logfilename, in order to avoid clashes while accessing the file. This can be done by adding the string "{ProcessId}" to the log file name. The specified string will be replaced by the actual process id used by the current instance.

L2 cache considerations

Empty cache after recycling
Since the second level cache is stored in memory, the cache gets deleted once the application pool is recycled. Therefore it doesn't matter if it uses overlapped recycling or not.

Accessing MSMQ in distributed cache environments
Besides the basic configuration of the L2 cache described here, there are a few things to consider when using this technology in web environments.

1. Since Telerik OpenAccess ORM uses the queues exclusively, in case of overlapped recycling, this can cause problems accessing the queue if there is only one queue specified. It is possible to solve this problem by specifying more than one queue that can potentially be used for the cache notification by adding semi-colon separated queue names to the configuration like in the following example:
If in this case queue1 can not be used because the 'old' web application process is still using it, Telerik OpenAccess ORM tries to use queue2. 

2. It must be ensured that the user specified for the application pool will have access to the configured queues used by the second level cache. This can be done by executing compmgmt.msc ->  Services and Applications -> MessageQueuing -> Private Queues

3. When IIS recycles the application pool then the openaccess process is terminated. In order to ensure that the handles to the MSMQ queues are freed, it is recommended to dispose the database object in the Application_End() method of the global.asax file. The following example demonstrates how to do this:


Having these considerations in mind, it is easy to safely set up Telerik OpenAccess ORM in web environments. Stay tuned as we will soon start lifting the curtain and presenting you the latest improvements in the product expected in Q3 2013!