Каков SQL Server Жизненный цикл Интеграции CLR?
Ваш цикл для повышения NameError. вы не можете получить доступ к элементам списка в цикле for, как этот. измените его на этот, чтобы напечатать желаемый результат:
for char in str1:
if char in list1:
print(char)
a
a
b
для печати своей позиции вы можете использовать index:
for char in str1:
if char in list1:
print(list1.index(char))
0
0
1
4 ответа
В "Сборках Pro SQL Server 2005" Робина Дьюсона и Джулиана Скиннера, в нем говорится, что «Сборки, загруженные в базу данных, как и другие объекты базы данных, принадлежат пользователю базы данных. Все сборки, принадлежащие одному и тому же пользователю в той же базе данных, будут работать в одном домене приложений. Сборки, принадлежащие другому пользователю, будут запускаться в отдельном домене приложения ».
Это говорит мне о том, что если вы работаете с одной базой данных и все сборки, которые вы загружаете с помощью оператора CREATE ASSEMBLY, имеют одного и того же владельца, то все ваши сборки будут работать в одном домен приложения. Однако нахождение в одном домене приложения не означает использование одной и той же базы кода, поэтому даже одна и та же dll может быть загружена в одни и те же домены приложения несколько раз, и ее типы не будут совпадать, даже если они имеют одинаковое имя. Когда типы с одним и тем же именем взяты из разных баз кода, их статические переменные также будут разными экземплярами.
Единственный способ, которым я могу безопасно использовать статические переменные в среде CLR SQL Server с несколькими сборками, - это просто использовать единая сборка. Вы можете использовать утилиту ILMerge с опцией «UnionMerge», чтобы упаковать все ваши сборки в одну и объединить классы с тем же именем. Это должно гарантировать, что для данной базы данных в вашей единственной сборке ваши статические переменные будут работать так же, как в автономном приложении. Я думаю, можно с уверенностью предположить, что домен приложения не выгружается и не перезагружается при каждом запросе, но вы можете '
Вот некоторая информация, которую я нашел.
Проблемы с общим состоянием и анонимными делегатами в SQLCLR
Мало того, что общее состояние не позволяется в НЕНЕБЕЗОПАСНОМ блоке, но анонимных делегатах (к сожалению), инициировали это ограничение "общего состояния".
От спецификации 3.0 (5.1.1) C#
Статическая переменная появляется перед казнью статического конструктора (§10.12) для его содержания типа и прекращает существование, когда связанный домен приложения прекращает существование.
Конечно, это не собирается закрывать целый домен приложения после каждого вызова, поскольку это было бы немного неэффективно. Таким образом да, эти статические объекты остаются там, пока база данных не остановлена или перезапущена.
SQL Server разрешает статические элементы только для чтения, если сборка развернута с небезопасным уровнем разрешений.
Практически объекты сохраняются в памяти до тех пор, пока служба SQL не будет остановлена / перезапущена.
Что касается параллелизма, ваш объект и методы должны быть потокобезопасными, как и везде.
Например:
public static class MyCLRClass
{
private static readonly ReaderWriterLock rwlock = new ReaderWriterLock();
private static readonly ArrayList list = new ArrayList();
private static void AddToList(object obj)
{
rwlock.AcquireWriterLock(1000);
try
{
list.Add(obj);
}
finally
{
rwlock.ReleaseLock();
}
}
[SqlProcedure(Name="MyCLRProc")]
public static void MyCLRProc()
{
rwlock.AcquireReaderLock(1000);
try
{
SqlContext.Pipe.Send(string.Format("items in list: {0}", list.Count));
}
finally
{
rwlock.ReleaseLock();
}
}
}
Я использую такие вещи в SQL CLR, и это работает.