2010年8月6号---PDS之主要数据管理和存储内容解析

2010年8月6号---PDS之主要数据管理和存储内容解析

以下内容是对较低版本的RedDwarf的主要内容的汇总，来自于帮助文档，但是这都是个人的理解和记录，方便我自己阅读，会有很多翻译的不好，如果有兴趣的朋友应该只作为参考，具体的请阅读帮助文档。

Goals and Philosophy
为了理解PDS的代码模式，理解它的目标或许会有帮助。它的基本目标如下：
* 以一种针对程序开发者显而易见的方式来保证服务端游戏代码的可靠性、可升级性以及良好的容错性。
* 以一种单线程事件驱动的程序模型呈献给开发者。开发者永远都不用将自己的代码错误归罪于代码在执行不同事件时可能出现的错误。

Approach to Execution
Task and Managers

从PDS应用程序开发者的角度来看，PDS应用程序执行以一种看上去是单播螺纹（monothreaded）、事件驱动的模型。代码处理事件机制满足了代码编写者对自己所做任何数据修改的唯一所有权。那么，应用程序执行就会是race-proof和deadlock-proof.在大多数条件下没有必要写同步的应用程序代码，而且事实上，如果试图使用synchronized关键字在ManagedObject将会引发一些微小的bugs。

事实上，系统会有很多线程来控制所有的同时处理的事件。这些控制线程被称作Tasks。系统会记录哪一个task能够访问什么数据。如果这其中task之间出现了冲突，那么其中一个task会失败并且会按照规定在晚一些的一个事件重试，这样另外一个task就能够完成事件并且跳出冲突。

Tasks是由PDS Manager来生成。一个PDS应用程序会在PDS环境中或者外部世界中使用这些manager来实现各种功能。

在系统中，有三种标准管理器。另外一些其他类型的管理器也会被编写和加入到PDS环境中。这三种标准管理器是：

* Task Manager
   一个PDS应用程序可以使用Task Manager来排列它所拥有的任务。Tasks可以被排列为即时执行、延迟执行或者周期性执行。又其他tasks穿件的task被称作是child tasks.这些来排列child task的task被称作是parent task。有多重child tasks被一个parent tasks所排列那么这些child tasks被称作是sibling tasks(兄妹task)。

* Data Manager
   一个PDS应用程序可以使用Data Manager来创建和访问持久化的和分布式的对象，这些对象被称作是Managed Objects。而PDS应用程序本身就是由这些Managed Objects组成的。

* Channel Manager
   一个PDS应用程序可以使用Channel Manager来创建和控制发布或者是认证数据通道（Channel Data）。这些数据通道被用来在一群客户端和服务器之间的通信。

一个PDS应用程序通过AppContext类来获得对PDS功能性代码的访问，AppContext来提供方法包含各种Managers的引用。

Task Ordering

Tasks被保证顺序执行由客户端产生的事件。一个Task处理一个客户端事件会在所有的比它早的所有的来处理该客户端事件的tasks执行完之后才会执行。一个子事务被排序是和它的父事务有关的，而不是和它的兄妹事务有关。这就意味着一个子事务在它的父事务完全执行完之前是不会执行的。同时，这并不会保证兄妹事务之间的执行回按照顺序。

Important: 在系统中，并没有其他的顺序执行的保证。尤其是，那些来执行不同用户的事件的事务的执行并不会被保证按照它们到达服务端的顺序关系来决定谁先开始执行。

Task Lifetime

Tasks必须是短生命周期的这就决定了它们不会阻塞过度占用其他事务访问资源的时间。PDS被配置为它的操作都有一个最大的时间限制。任何一个在规定时间内没有完成的task都将会被强制终止。

如果你的一个task运行时间过长，那么就会有两种倾向于减少运行时间的方法：
* 把它切分为一连串子事务，每一个子事务处理一段彼此没有联系的该问题的一部分，然后按照先后次序执行顺序执行下一个子事务。这就是所谓的continuation-passing 模式。

* 将那些时间要求强烈计算放入一个特定的manager中区，最后产生一个顺序的任务结果。

Managed Objects and Managed References

DataManager维护着那些持久化的存储在一个对象池中的Managed Objects，这个对象池叫做Object Store。像每一个普通的Java对象，每一个Managed Object包含数据和方法两样来数据进行处理。作为一个Managed Objects,这个对象必须要实现ManagedObject和Seriablizable接口。一个Managed Object并不会成为对象存储池中的一员，直到对象存储池意识到了它。而意识到它就需要使用Data Manager为这个对象请求一个Managed Reference或者为这个对象绑定一个名字。

一个Managed Reference 是一个引用对象类似于J2SE中的引用对象（比如：SoftReference,WeakReference）。Managed Objects必须提交到其他的Managed Ojbects之中去。这就是Data Manager能够告诉你一个Managed Object的一个组件的引用作为一个列表中的Managed Object的状态和一个分离的Managed Object它自己的状态之间的不同的原因。

一个name绑定用一个字符串来和Managed Object绑定起来，这样其他的tasks(事务)就会在Data Manageer中通过getBing来唤回这个对象。

Accessing Managed Objects through Managed Reference

Managed Reference有两种方法方法：get方法和getForUpdate方法。这两种方法都会返回这个对象的一个本地task(task-local)的引用。这两种方法的区别是：
* getForUpdate 通知系统你将会修改Managed Object 的状态。
* get 告诉你将会只是读取这个状态而不会写入它。

尽管会有持续不断的修改来操作与任何一个Managed Object，但是在你知道在什么时候修改Managed Object 的状态时，使用getForUpdate会更加有效。这个方法允许系统取法心爱你不同事物并且会让他们更早更加有效的处理之间的冲突。

反过来说，如果不对Managed Object的状态值进行修改，那么使用get方法会更好一点。在多事务情况下get方法的调用会允许有更多的平行访问对于Managed Object。如果你到达这个状态的修改点比较晚了一点，但是你要修改这个状态值，那么你可以升级你的get方法到getForUpdate方法利用Data Managed 的markForUpdate方法。多事务处理过程中，对同一个Managed Object调用升级是无害的。

在同一个事务中，后续的和前边的具有相当的Managed Reference那么调用get和getForUpdate将会返回相同的task-local拷贝。

你也可以利用getBinding方法利用bound name返回一个Object Store中的Managed Object。
一旦Object Store中有的Managed Object被意识到了，那么它就会保持这个对象的状态值，直到Data Manager调用removeObject方法从Object Store中明确的删除了这个对象。应用程序负责管理Object Store中的Managed Object 的生命周期，并在他们永远不再需要的时候删除它们。但是Object Store中垃圾的逐渐增多可能会影响它的行为，导致操作失败。同样的，存储的name binding的对象，会通过removeBinding 方法明确的移除。一个name binding对象的引用被移除，那么它就会被销毁。