. NET Remoting механизм блокировки резьбы

У меня настоящая проблема, и я надеюсь, что вы все можете мне помочь. Я постараюсь изо всех сил объяснить это, как я могу.. NET Remoting механизм блокировки резьбы

Я дополняю систему, использующую удаленную удаленную сеть .NET, чтобы разрешать вызовы базы данных с тонкого клиента на сервер, который выполняет указанные вызовы. На самом сервере есть установленные на нем компоненты доступа к данным, поэтому он делает фактические вызовы в базе данных и просто возвращает datarows тонкому клиенту.

Я только недавно добавил транзакции к этим модулям. Я хотел сделать это потокобезопасным, где, если клиентский поток A запустил транзакцию базы данных, клиентский поток B не сможет получить доступ к транзакции потока клиента A. Нет необходимости разрешать клиентскому потоку B иметь свою собственную транзакцию в то же время, только необходимо, чтобы я не разрешал клиентскому потоку B использовать транзакцию потока клиента А.

Существует только 1 ссылка на удаляемый объект, который они разделяют, и из-за базовой архитектуры, в которую я не попаду, я не могу это изменить. Все объекты Transaction хранятся на сервере в этом удаленном объекте.

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

Если бы был какой-то способ связывания клиентского потока с удаленным доступом процесс нить, я думаю, что будет делать трюк, но нет никакой документации, что я мог бы найти на такую вещь.

Я надеюсь, что я объяснил это достаточно хорошо. Вся помощь очень ценится. Спасибо заранее.

источник

2010-01-22 jnadro52

Я не уверен на 100%, если это можно сделать, но использование CallContext может помочь. В двух словах CallContext - это данные Out-Of-Band, которые могут быть удалены на сервер, см. Th это блог here для примера. Если вы не понимаете, что такое Out-Of-Band (oob), посмотрите here на wikipedia. Вот еще один конкретный пример here. Это может дать вам ключ.

источник

2010-01-23 00:07:16 t0mm13b

Благодарим вас за это предложение. Я не знал о CallContext, и это могло мне очень помочь. Я просто не знаю, как я могу гарантировать, что информация о потоке всегда будет передана. Кажется, что мне нужно будет убедиться, что контекст потока задан для каждого вызывающего потока, который может быть неосуществимым с моими временными рамками. Есть ли какое-то событие, которое запускается перед удаленным вызовом, в котором я могу установить callcontext для этого потока? Или callcontext сохраняет ссылку на информацию о потоке по умолчанию? Это было бы большой помощью для меня! Спасибо. – jnadro52

@ jnadro52: Я полагаю, что перед выполнением удаленного вызова задайте контекст вызова с идентификатором на стороне клиента, а затем на стороне сервера, в функции, которая является удаленным вызовом клиента, сначала прочитайте контекст callcontext и создайте коллекцию , таким образом вы бы знали, какой клиент использует поток. Единственное, что коллекция должна быть потокобезопасной .... – t0mm13b

То, что вы пытаетесь сделать звучит любопытное странно, поэтому позвольте мне увидеть, если я понимаю:

Вы используете одноплодный на стороне сервера, поэтому каждый клиент имеет только 1 резьбу на сервер.
Предполагая, что процесс транзакции занимает много времени (от нескольких секунд до нескольких минут), другие клиенты ДОЛЖНЫ дождаться завершения первого клиента.

Я думаю, но я не уверен, что вызов каждого клиента создает свою собственную нить. Если это так, то просто реализовать некоторые «блокирующие» вызовы, когда удаленный объект должен создавать потокобезопасные вызовы, должен сделать трюк. Блокировка является дорогостоящей, и если транзакция занимает несколько секунд, другой ожидающий может истечь тайм-аут (eeK!)

Это тот материал, который был создан для объекта TransactionScope для (See MSDN). Я больше не могу помочь, не зная больше об арке решения.

Извините ... Я не знаю, полезно ли это или нет.

источник

2010-01-23 01:05:08

Да, это одноэлемент, я должен был упомянуть об этом ранее. У меня был механизм фиксации нити с помощью монитора. Я реализовал это на стороне сервера. Это вызывает проблемы, поскольку идентификатор потока продолжает изменяться на стороне сервера, даже когда тот же клиентский поток вызывает удаленный объект. В этом суть проблемы ... как заблокировать процесс на стороне сервера и убедиться, что другой клиентский поток не имеет доступа к объекту транзакции потока, который создал объект транзакции? Если бы у меня был какой-то способ передачи информации о потоке, тогда это было бы возможно. – jnadro52

@ jnadro52: Мне нравится метод контекста вызова, предложенный tommieb75 как средство для определения того, является ли он одним и тем же вызывающим (вроде как состояние сеанса) и использует поточно-безопасную коллекцию из фреймворка. Я предполагаю, что это означает, что вам может потребоваться передать объект соединения и использовать его в каждом вызове базы данных, чтобы убедиться, что вызов выполнен в транзакции. – 2010-01-28 21:19:13

. NET Remoting механизм блокировки резьбы

ответ

Смежные вопросы