Что сериализация по умолчанию используется ASP.net HttpRuntime. Кэш
Просто удивление, если кто-либо знает окончательно что сериализация по умолчанию, используемая ASP.net HttpRuntime. Кэш? Действительно ли это является Двоичным, XML, что-то еще?
Я спрашиваю, потому что у меня есть ситуация, где я заполняю универсальный Список с несколькими объектами того же пользовательского типа. Пользовательский тип ПОСТЕПЕННО, нет ничего специального об этом. Все его свойства общедоступны с {добираются; набор;}, это общедоступно, это не имеет никакого наследования, это не имеет никаких интерфейсов. На самом деле это намного менее сложно, чем много других объектов, которые мы кэшируем который работа без проблемы. Я попытался добавить [сериализуемый] атрибут к пользовательскому классу, и он не имеет никакого эффекта.
Я добавляю список к кэшу с уникальным ключом. Список был проверен, как заполнено, прежде чем он будет вставлен в кэш, объекты в списке были проверены, как заполнено также. Но когда список вытащен назад из кэша, это - пустой список (NOT NULL), он просто не имеет никаких объектов в нем. Это означает, что список добавляется к кэшу и восстановим, но по некоторым причинам кэш имеет проблемы, сериализирующие объекты в списке.
Я просто нахожу это причудливым странный, так как у меня есть другой список пользовательских объектов, которые намного более сложны (состоящий из Наследования, Интерфейсов, и также содержащий Свойства, которые являются универсальными списками других сложных объектов), и кэширование тех списков работа без проблемы.
И работа и нерабочий список организуются в классах C# за пределами пользовательских элементов управления ASP.net, которые используют кэшированные данные. Оба из этих, которые кэш, обрабатывающий классы, называет тем же самым одноэлементным экземпляром класса Диспетчера кэша, который переносит HttpRuntime. Кэш для обеспечения введенных методов для получения по запросу и продвигающих объектов в кэш.
У кого-либо есть какие-либо идеи, что могло заставить это происходить. Единственная вещь, из которой я могу утончиться, состоит в том, что свойство 'Blurb' Объекта документа может потенциально содержать HTML, но если бы ASP.net использует двоичную сериализацию для кэша, я не вижу, как это сделало бы что-либо.
Вот класс
public class Document
{
public string ContentTypeId { get; set; }
public string ContentId { get; set; }
public bool IsCustom { get; set; }
public Language DocLanguage { get; set; }
public string RegularTitle { get; set; }
public string InvertedTitle { get; set; }
public string Blurb { get; set; }
}
Вот подкласс, используемый в Свойстве Языка
public class Language
{
public string Name { get; set; }
public string Code { get; set; }
}
2 ответа
Несколько более подробно относится к окружающей среде, в которой происходит эта аномалия кэширования.
У меня есть контроль пользователя ASP.NET, который представляет собой контейнер с вкладками на странице. Этот контроль содержит список тем, выбранных пользователем. Для каждой темы пользователь выбрал этот элемент управления создает новую вкладку для этой темы, содержащей документы, связанные с этой темой.
Контроль создает новую вкладку, используя ASP.NET, предоставленный методом LoadControl. Затем он назначает вновь созданную вкладку Control в тему из его списка. Каждое управление вкладками знает, как найти документы для его назначенной темы.
Это на табуке управления, где была реализована кэширование. Ключ кэширования, используемый для кэширования списков документов, полностью уникален для сайта + тема + гендерный возраст пользователей, просматривая тему. Это позволяет кэшировать списки документов и получить через сайт всех пользователей, соответствующих этим критериям.
Хорошо, когда списки документов были переданы в кэш, они были переданы обычными старыми ссылками объекта (I.E. Список документов = _documents). Но когда вытащил из кеша, список были пустыми.
Хотя каждое управление вкладками является его собственный экземпляр одного и того же элемента управления пользователя, и все переменные, используемые на элементе вкладки, являются частными для этого элемента управления и должны быть специфическими для этого контроля. Я ударил конец своей веревки и несмотря на то, что нет никакого способа, которые индивидуальные вкладки не могут быть переоценены в письменной форме, я решил, что пришлось быть какой-то сумасшедший справочник, и если это было то, что мне нужно было Чтобы остановить использование ссылок объектов в кэше и отправьте кэш полностью новых копий списков, которые я пытался хранить.
Затем я использовал следующий метод расширения для списка <> и клонировал каждый список, поскольку их передавали в кэш. Это сделало его так, чтобы все предметы, переданные к кэше, были совершенно новые объекты с собственным пространством в памяти со своими уникальными ссылками на эту память.
Исправлено его. Кэширование сейчас работает. Списки теперь возвращаются точно так, как они были добавлены в кэш. Я понятия не имею, почему это будет иметь значение, если у кого-то есть идеи, которые я хотел бы слышать их.
/// <summary>
/// Clones the specified list to clone.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="listToClone">The list to clone.</param>
/// <returns></returns>
public static IList<T> Clone<T>(this IList<T> listToClone) where T : ICloneable
{
return listToClone.Select(item => (T)item.Clone()).ToList();
}
Expression<Action<Thing>> exp = o => o.Method(1, 2, 3);
var methodInfo = ((MethodCallExpression)exp.Body).Method;
var names = methodInfo.GetParameters().Select(pi => pi.Name);
По данным отражателя, HTTPRUNTIME.CACE не сериализует данные вообще, он просто хранит его в памяти в Hashtable .
Вы говорите, что оберните вызовы к кеше внутри своего собственного объекта Singleton. Почему ты делаешь это? httpruntime.cache - это статическое свойство, и поэтому ваши методы обертки также могут быть статичными.