#160 ResourcePeer and MemResource design

brian Sun 2 Dec 2007

I've gone through a few designs, and I've settled on one I'm pretty happy with. The basic idea is that Resource doesn't implement any functionality itself, but instead delegates everything to its ResourcePeer. Some of the aspects of this design:

  • Resource routes every single method to its ResourcePeer
  • Resource and ResourcePeer are bound together in the ResourcePeer constructor
  • Resource doesn't have any virtual methods, all overrides are done in Java/C# code
  • You are forced to implement everything in Java or C# code (a goal of my design)
  • Implementation methods can be limited to Java or C#, not exposed to Fan API
  • Native peers for Resources subclass ResourcePeer (or MemResourcePeer)
  • Native peers override ResourcePeer methods (don't use normal native signatures)

Effectively Resource and MemResource are just very simpler wrapper objects for ResourcePeer.

A key class is MemResourcePeer which implements a memory backed resource. MemResource supports mounting children, which are themselves backed by MemResourcePeers. MemResourcePeer can also store a arbitrary Fan object (either immutable or serializable). The MemResourcePeer design is based on a "master" instance and "working" instances to keep everything thread safe. The core design for memory resources is simplistically based on "multiversion concurrency control" ( http://en.wikipedia.org/wiki/Multiversion_concurrency_control) where each thread gets its own "working snapshot". If you save a working snapshot and the current version of the master has been updated since the working snapshot's read, then the save fails. I'm thinking eventually we allow you to pass in a Func to resolve the conflict.

The Sys.namespace root itself is backed by a MemResourcePeer. As such the root of the tree and the top level branches are also required to be backed by MemResourcePeers. Eventually the "virtual" branches of the tree are backed by subclasses of MemResourcePeer which can mount into namespace as normal memory resources, but implement their children using another strategy (such as file, database, or network access).

To verify this design, I stubbed out the sql::TableResource. The TableResourcePeer subclasses MemResourcePeer - so it can be mounted into the memory space to serve as the glue between the top of namespace tree and the rows in a database. There is a basic test suite stubbed out in sql::ResourceTest.

Login or Signup to reply.