对于昨天的一文中，还缺少一个对对象池问题的想法，今天拿出来。
有一天出去买了水果，回家我就把它们送进了冰箱，突然间有了个想法，主要是对对象池的想法，在技术实现上应该不是很难做到。想法如下，冰箱内根据温度分成不同的储藏区域，温度由高向低，最低温度的部分，我经常用来制作冰块。那么我想，App Server的对象池应该像这样也分成一个区域，不过不是根据温度哦！应该根据被池化的对象使用的频度和使用的状态来分区，虽然我在对象池中已经加入了收缩的功能，但是仍然不满意的一点是，在大负载的情况下，内存仍然吃紧，可伸缩性受到了影响，所以池化的对象按如下规则分区！
但是每个分区都是一“群”小的池组成，这些小的池由同一性质的不同类型的对象组成，也就是说一个类型的对象对应一个小池（叫作Ice Block).
对于入池:
1）刚刚被使用完毕，并且不是中间停顿的对象，并且使用频率相对较高，此时它被“安置”在第一区(取个名字“Z-Zone"),如果有新的请求到来服务器请求分发器首先检查这一区的情况,并查出对应类型的ICE Block,并从其中得到一个对象的引用，同时传递请求。这个区活跃在与App Server相同的进程中，也就是说服务器一旦Over，这个池也就会Over.
2）刚刚被使用，但被堵塞，此时对象被安置在第二区（名字叫"State-Zone"),并且一个对象的中某个方法的调用信息和输入的参数会被“保护”起来（使用消息队列），并在重新激活的时候重放。第二区活跃在不同于App Server的另外一个进程（可能是一个CLR上其他的一个进程，也可能是其他CLR上的一个进程，根据配置信息而定），此时即使App Server Over掉，在App Server重新启动的时候，还会得到这个区域的池，除非池所在的机器的操作系统或者此进程被Kill掉，才会使这个池Over.保全性相对Z-Zone较高。
3) 相对没有被经常使用，服务器不希望它占用内存太久，因为暂时它还没有客户端调用，并且根据一个Timeout设定，如果超时没有人使用，服务器虚拟运行时会自动将其“安置”在第三区（名字叫"File-Zone"),也就是说会被序列化成文件系统的XML文件并保存起来,同时从内存中把这个对象销毁掉释放一切相关资源,为了应用程序方便的使用此区,服务器提供虚拟视图,看上去和其他池没有什么不同,API和其他区一致,内部的序列化和反序列对程序而言是透明的. 这个池是个持久化池,但是是一个没有优化的池,生命周都要比前两个要长.这个区有个优点,就是能够将一个存有对象信息的XML文件拷贝到另外一个App Server的同样配置的应用中,使得另外一个应用可以接手第一个应用的工作,用户甚至可以用一个磁盘装载这个区的清单文件和XML文件以及请求数据文件,到另外一地方再继续执行业务!比如用户设定应用提升File-Zone的优先级,此时前两个区的功能会被禁用,用户就可以使用移动设备版的App Client(没有服务器功能的一个客户端虚拟运行时)在一个PDA上写入数据并提交请求,但是可以不与服务器相连接,等有活跃连接时,自动将已经序列化的文件Copy被Server,此时在服务器上恢复了执行.
4)很久没有被使用的对象,会被应用服务器虚拟运行时"安置"在第四区(叫作"Body-Zone"-放尸体的地方),它是将对象以二进制的形式存入一个配置好的数据库管理系统,默认是MS SQL Server,由于SQL Server有数据库引擎,能够提供良好的内存管理和优化,所以此区可以看作是File-Zone的优化级.
对于出池:
1)为了保证数据的保护与同步,在对象出池时会带着上下文事务出来,但是每个区的事务管理方式不尽相同,这是由他们的性质决定的,具体想法,稍后再放出.....
有一天出去买了水果，回家我就把它们送进了冰箱，突然间有了个想法，主要是对对象池的想法，在技术实现上应该不是很难做到。想法如下，冰箱内根据温度分成不同的储藏区域，温度由高向低，最低温度的部分，我经常用来制作冰块。那么我想，App Server的对象池应该像这样也分成一个区域，不过不是根据温度哦！应该根据被池化的对象使用的频度和使用的状态来分区，虽然我在对象池中已经加入了收缩的功能，但是仍然不满意的一点是，在大负载的情况下，内存仍然吃紧，可伸缩性受到了影响，所以池化的对象按如下规则分区！
但是每个分区都是一“群”小的池组成，这些小的池由同一性质的不同类型的对象组成，也就是说一个类型的对象对应一个小池（叫作Ice Block).
对于入池:
1）刚刚被使用完毕，并且不是中间停顿的对象，并且使用频率相对较高，此时它被“安置”在第一区(取个名字“Z-Zone"),如果有新的请求到来服务器请求分发器首先检查这一区的情况,并查出对应类型的ICE Block,并从其中得到一个对象的引用，同时传递请求。这个区活跃在与App Server相同的进程中，也就是说服务器一旦Over，这个池也就会Over.
2）刚刚被使用，但被堵塞，此时对象被安置在第二区（名字叫"State-Zone"),并且一个对象的中某个方法的调用信息和输入的参数会被“保护”起来（使用消息队列），并在重新激活的时候重放。第二区活跃在不同于App Server的另外一个进程（可能是一个CLR上其他的一个进程，也可能是其他CLR上的一个进程，根据配置信息而定），此时即使App Server Over掉，在App Server重新启动的时候，还会得到这个区域的池，除非池所在的机器的操作系统或者此进程被Kill掉，才会使这个池Over.保全性相对Z-Zone较高。
3) 相对没有被经常使用，服务器不希望它占用内存太久，因为暂时它还没有客户端调用，并且根据一个Timeout设定，如果超时没有人使用，服务器虚拟运行时会自动将其“安置”在第三区（名字叫"File-Zone"),也就是说会被序列化成文件系统的XML文件并保存起来,同时从内存中把这个对象销毁掉释放一切相关资源,为了应用程序方便的使用此区,服务器提供虚拟视图,看上去和其他池没有什么不同,API和其他区一致,内部的序列化和反序列对程序而言是透明的. 这个池是个持久化池,但是是一个没有优化的池,生命周都要比前两个要长.这个区有个优点,就是能够将一个存有对象信息的XML文件拷贝到另外一个App Server的同样配置的应用中,使得另外一个应用可以接手第一个应用的工作,用户甚至可以用一个磁盘装载这个区的清单文件和XML文件以及请求数据文件,到另外一地方再继续执行业务!比如用户设定应用提升File-Zone的优先级,此时前两个区的功能会被禁用,用户就可以使用移动设备版的App Client(没有服务器功能的一个客户端虚拟运行时)在一个PDA上写入数据并提交请求,但是可以不与服务器相连接,等有活跃连接时,自动将已经序列化的文件Copy被Server,此时在服务器上恢复了执行.
4)很久没有被使用的对象,会被应用服务器虚拟运行时"安置"在第四区(叫作"Body-Zone"-放尸体的地方),它是将对象以二进制的形式存入一个配置好的数据库管理系统,默认是MS SQL Server,由于SQL Server有数据库引擎,能够提供良好的内存管理和优化,所以此区可以看作是File-Zone的优化级.
对于出池:
1)为了保证数据的保护与同步,在对象出池时会带着上下文事务出来,但是每个区的事务管理方式不尽相同,这是由他们的性质决定的,具体想法,稍后再放出.....
