使用 JointCode.Shuttle 管理远程服务对象的生命期

JointCode.Shuttle 是一个用于进程内 AppDomain 间通信的服务架构(不支持跨进程)。

一般情况下,在进行跨 AppDomain 调用时,大部分人选择使用运行时库默认提供的、基于 MarshalByrefObject 类继承的通信机制。代码也很简单,例如:

 1 namespace JoitCode.Shuttle.SimpleSample
 2 {
 3     public class MyService : MarshalByRefObject
 4     {
 5         public void Do() { }
 6     }
 7
 8     class Program
 9     {
10         static void Main(string[] args)
11         {
12             // 在默认 AppDomain 中创建一个子 AppDomain
13             var serviceDomain = AppDomain.CreateDomain("ServiceDomain", null, null);
14
15             var myService = (MyService)serviceDomain.CreateInstanceAndUnwrap
16                 (typeof(MyService).Assembly.FullName,
17                  "JoitCode.Shuttle.SimpleSample.MyService");
18
19             myService.Do();
20
21             Console.Read();
22         }
23     }
24 }

使用这种方式来调用远程(位于其他 AppDomain 的)服务,简单固然简单,但它不提供远程服务管理功能。也就是说,调用者无法控制何时释放远程服务对象。

假如远程服务对象只是提供简单的服务,这本来也没什么问题。但如果远程服务可能会被频繁调用呢?又或者远程服务持有关键系统资源(因而需要及时释放)呢?

前一种情况可能会造成服务端内存消耗增加,而后一种情况则可能造成系统瓶颈。

使用 JointCode.Shuttle 可以避免上述情况的发生,因为它允许客户端自主释放远程服务对象,或者也可以使用租约来管理远程对象的生命期。而且,如果远程对象实现了 IDisposable 接口,则其 Dispose 方法还会被调用(注意,如果服务被定义为单例,即在对服务类应用 ServiceClassAttribute 时将其 Lifetime 属性设为 LifetimeEnum.Singleton,则要到应用程序结束时才会释放其服务实例并调用其 Dispose 方法)。

使用方法类似如下所示:

    IRemoteLifetimeService lifetimeService;

    // 获取远程服务实例
    // _shuttleDomain 是一个 ShuttleDomain 实例对象
    _shuttleDomain.TryGetService(out lifetimeService);

    // 调用远程服务方法
    lifetimeService.Execute();

    // 远程服务对象会被释放
    lifetimeService.Dispose();

我们为此编写了一个简单的测试,如需获取完整的测试源码,请点击 此处 下载(测试名称:ShuttleDomain生命期管理)。

时间: 2024-11-05 21:46:36

使用 JointCode.Shuttle 管理远程服务对象的生命期的相关文章

JointCode.Shuttle,一个简单高效的跨 AppDomain 通信的服务框架

JointCode.Shuttle 是一个用于 AppDomain 间通信的服务架构. 1. 什么情况下使用 JointCode.Shuttle 在 .net / mono 开发中,一般不太需要使用额外的 AppDomain,但在一些 特定情况下,让代码运行在新的 AppDomain 中也许是一个好的选择. 当代码需要跨越 AppDomain 边界访问另一个 AppDomain 时,便产生了跨 AppDomain 通信的问题,JointCode.Shuttle 正是专为此目的而开发的一个服务框架

使用 JointCode.Shuttle 进行跨 AppDomain 通信的一个简单示例

JointCode.Shuttle 是一个用于进程内 AppDomain 间通信的服务架构(不支持跨进程). 本文通过一个简单的示例来演示如何使用 JointCode.Shuttle. JointCode.Shuttle 的发行包 在 JointCode.Shuttle 的发行包中,包含两个文件:JointCode.Shuttle.dll 和 JointCode.Shuttle.Library.dll,其中 JointCode.Shuttle.dll 是使用托管语言编写的库文件,JointCod

使用 JointCode.Shuttle 访问任意 AppDomain 的服务

JointCode.Shuttle 是一个用于进程内 AppDomain 间通信的服务架构(不支持跨进程). 本文主要介绍如何通过 JointCode.Shuttle 访问任意 AppDomain 的服务. 当我们要进行跨 AppDomain 调用时,一般我们会让需要跨 AppDomain 操作的类(服务类)继承自 MarshalByrefObject,接着在调用 AppDomain(父 AppDomain)中创建目标 AppDomain(子 AppDomain),然后直接通过子 AppDoma

ansible批量管理远程服务器

使用ansible批量管理远程服务器 背景 本地需要管理远程的一批服务器,主要执行以下任务: 1) 将本地的文件复制到远端所有服务器:  2) 需要在远程服务器中执行一个个命令: 远端服务器路径并非完全一致,一般访问通过环境变量中定义的变量路径访问:  比如在.bashrc中定义$app_path=/opt/app/bin 最终选择ansible,使用这个自动化运维工具可以满足我的需求:  下面介绍下对于我这种场景需要使用的ansible的主要模块:  关于ansible是什么以及安装配置请自行

面向服务开发中三层架构中事务单元的生命期管理

    经典的三层分层结构,控制层(Control),服务层(Service),持久层(Repository)应用广泛,在面向服务(SOA)的架构中,配合DI.IOC实现开放灵活的技术架构.     SOA中,Respository面向数据访问,提供访问数据库.文件.或其他业务接口提供持久能力.Service面向业务,提供访问业务功能的接口,使用领域模型描述业务需求,方便产品人员.需求人员和客户沟通理解业务流程.最后,Control面向业务流程整合,提供基于事务的需求实现.     事务,用需求

Android百日程序: Fragment动态管理和生命期

之前写过Fragment使用的程序,Fragment可以静态,也可以动态载入内存中的,这一章进一步看看如何动态地更换Fragment和看看Fragment生命期都有什么函数. 本章利用响应菜单点击事件,轮流载入不同的Fragment,显示不同的界面,效果如下: 开始的是没有载入Fragmen为空白: 点击菜单的NEXT FRAGMENT VIEW,就进入下一个界面,载入两个: 继续点击显示Fragment 1: 继续点击,显示Fragment2: 然后就是循环了: 如此循环显示不同画面. 一 首

从本机IIS中管理 远程服务器 IIS

有时候,一般情况下,我们对服务器上 IIS 上的管理局限于 使用远程桌面:现在介绍一种,通过  本机 管理管理远程IIS 的方法! 1. 服务器端设置: 服务器管理器 ==>增加角色和功能向导==>勾选  管理服务   安装. 1)如图所示安装     2)安装完成之后,远程 的 IIS 中  安全性 一栏中  会 出现  管理服务 选项. 3)启用远程连接,设置好之后,右侧 启动服务. 2. 客户端 本机电脑:  1). 本机电脑 下载安装  IIS Manager for Remote A

关于FragmentManager动态管理Fragment时Fragment生命周期的探究

Fragment是Android中的重要组件,在Android 3.0的时候添加进来. 关于Fragment的生命周期,我相信了解过的开发人员都应该把以下方法脱口而出:onAttach, onCreate, onCreateView, onViewCreated, onActivityCreated, onStart, onResume, onPause, onStop, onDestroyView, onDestroy, onDetach. 当Fragment以静态的方式,即通过在布局文件中以

使用ansible批量管理远程服务器

使用ansible批量管理远程服务器 背景 本地需要管理远程的一批服务器,主要执行以下任务: 1) 将本地的文件复制到远端所有服务器: 2) 需要在远程服务器中执行一个个命令: 远端服务器路径并非完全一致,一般访问通过环境变量中定义的变量路径访问: 比如在.bashrc中定义$app_path=/opt/app/bin 最终选择ansible,使用这个自动化运维工具可以满足我的需求: 下面介绍下对于我这种场景需要使用的ansible的主要模块: 关于ansible是什么以及安装配置请自行百度: