Совместное использование кэша базы данных Enterprise Library между несколькими приложениями - PullRequest
Новая
       10

Совместное использование кэша базы данных Enterprise Library между несколькими приложениями

0 голосов
/ 22 марта 2012

У меня странная проблема с блоком кэширования Enterprise Library 5, где два приложения совместно используют один и тот же кеш базы данных.Я написал очень простой класс статического менеджера кэша, который завершает создание Entacheibache ICacheManager и чтение / запись в него. 

private static ICacheManager _manager = null;

private static ICacheManager Manager
{
    get
    {
        lock (ClientLock)
        {
            if (_manager == null)
                _manager = CacheFactory.GetCacheManager();

            return _manager;
        }
    }
}

public static object Get(string cacheKey)
{
    return Manager.GetData(cacheKey);
}

public static void Add(string cacheKey, object cacheItem)
{
    Manager.Add(cacheKey, cacheItem);
}

Моя база данных настроена правильно, как и файлы конфигурации, и я могу читать изапись в кеш базы данных из одного консольного приложения без проблем.

Однако я пытаюсь провести тест между двумя приложениями, использующими один и тот же кеш.Кажется, проблема в том, что если класс Static CachingManager в Console_A добавляет элементы в Cache, то после того, как Console_B создал его статический CacheManager, изменения не будут восприняты Console_B.

Вот краткая временная шкала для объяснения.1008 * 

Start Console_A

Write Item1 from Console_A to Cache - (Static ICacheManager created with noticeable 1sec pause) Success - 1 Item in Cache
Write Item2 from Console_A to Cache - Success - 2 Items in Cache
Write Item3 from Console_A to Cache - Success - 3 Items in Cache

Start Console_B

Read Item1 from Cache to Console_B - (Static ICacheManager created with noticeable 1sec pause) - Success - 3 Items in Cache
Read Item2 from Cache to Console_B - Success - 3 Items in Cache
Read Item3 from Cache to Console_B - Success - 3 Items in Cache

Write Item4 from Console_A to Cache - Success - 4 Items in Cache (Confirmed in DB)
Read Item4 from Cache to Console_B - Failure - 3 Items in Cache

Таким образом, кажется, что когда Console_B изначально устанавливает свой менеджер кэша, он не возвращается в базу данных для обновления данных.Содержит

Я также пытался удалить чек if(_manager == null) из моего Собственности, чтобы он каждый раз вытаскивал new CacheManager с завода, но это не имело никакого значения.

Любой советприветствуется.

РЕДАКТИРОВАТЬ

Может показаться, что LoadItems Sproc вызывается только тогда, когда создается экземпляр ICacheManager, но никогда больше в течение жизненного цикла приложения, независимо от того, используете ли выснова вызвать CacheFActory / Unity EntLibContainer.

Ответы [ 2 ]

1 голос
/ 22 марта 2012

Область применения Console_A и Console_B различна.Даже если вы определили свой менеджер кэша как статический, он не будет существовать за пределами домена приложения, поэтому у вас есть два отдельных менеджера кэша, которые не знают друг о друге.

Я бы порекомендовал использовать сервис(WCF) и вызывая ваши бизнес-методы через эту службу, таким образом, все консольные приложения будут вызывать одну и ту же службу, и у нее будет один экземпляр диспетчера кэша, находящийся в его собственном домене приложений.

0 голосов
/ 22 марта 2012

Это по замыслу.

Блок кэширования корпоративной библиотеки спроектирован как внутрипроцессный кэш, и даже при использовании резервного хранилища на основе БД он используется только для восстановления состояния в случае перезапуска приложения. Он не был предназначен для использования в качестве распределенного кэша.

Ссылка: Крис Таварес - MS Patterns & Practices Team

...