Management Live Cycle of objects

Introduction

This article introduces memoization and a quick usage of WeakReference.

It's not a bad typo ; the term memoization is a real word. You can read this article in wiki.

Background

Memoization is a concept that appeared in 1991 around general studies of parser technologies. But the underlying concept of this term was already known by every programmer in games development; the idea that a game needs to be pre-addressed and all computations which had taken a longer time as needed if it was computed on the fly, were memoized.

To memoize an object is just the things that if you give the same parameters in a function call, and the function computes for a long time, you should memorize just the result and suppress the time consuming to recompute the result with same parameters.

The problems are:

1. What kind of parameters will you accurately memoize?
2. What are kind of algorithms useful to memoize?

Is memoization like the term "caching"? I answer that it is not.

Using WeakReference

Next in .NET, and first in Java, a weak reference is just like to give a chance to the computer's background work that it keeps the result for a short or a long time; and, if the target object has reclaimed by garbage collection, it means you need to compute again.

There is a clear definition of what is WeakReference and its usability:

• https://docs.python.org/2/library/weakref.html

Then, another way is to keep data by serialization. Also, serialization and memoization are similar concepts.

But, unfortunately, serialization is a process which takes, for instance, a relative memory size, time consuming and efforts code (and tests and maintaining, etc.). As you could serialize your data into a simple JSON string and hold this in an isolated storage (for example), it's a little bit too much effort for any data model which does not size less than 1Mo.

The relative effort to code these needs is not very interesting, if you just want something to keep your objects closely.

A Little Basis Starter

First, create a new AppDomain (the code below works with .NET v2):

AppDomainSetup ads = new AppDomainSetup();
ads.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;
ads.ConfigurationFile = AppDomain.CurrentDomain.BaseDirectory + "createAppDomain.exe.config";
ads.ApplicationName = "InnerApp";

Evidence ade = new Evidence();
ade.AddHost(new Zone(SecurityZone.MyComputer));

this._dom = AppDomain.CreateDomain("innerApp", ade, ads);

You can create a new Thread in this new AppDomain. And, in order to communicate between domains, you are using these methods:

/* around the primary domain */
object obj = this._dom.GetData("name");
/* around the inner domain */
AppDomain.CurrentDomain.SetData("name", obj);

While you are loading a big file, a big data from SQL or from an XML file, use the inner domain to handle it.
When you select your data and you ask the inner domain to restore some of them, deserialize and marshall data to the primary domain. Since data is cached by the inner domain, you create a WeakReference of the deserialized object from the primary domain.

While you want to post data between domains, use the callback delegate:

CrossAppDomainDelegate cross = new CrossAppDomainDelegate(() => {});
this._dom.DoCallback(cross);

And when you leave the object left, the WeakReference does that the garbage collector reclaims this object.
Finally, if you modify the content of the object, you may pass the serialized version to the inner domain.

The inner domain will replace, insert, delete any kind of changes into your database or into your file or else into your XML file, by a direct update.

Points of Interest

To the resulting implementation, you have the ability to map your objects for a temporary time line, life cycle even when you are canceling your changes. Each windows form (old & WPF) which binds to your object, are designed to accept any changes of the object or reject immediately all your change with no overrun.

In general, you keep objects in a list to give the ability to access them at any time. If you centralize your objects, you are taking advantage of a rough conception.

It will be interesting to leave these standard management cycle to something you can get your objects because they reside where you need them; for example, just into the methods to add, find, search, modify, delete objects regarding the object type you need to access.

I heard about memoization one week ago. In my opinion, it seems to be a great idea.

But, implementation and usage are not common.

To play with memoization, a big modelization effort is needed to reduce time consumption. And, usage of WeakReference is not the same objective but to enable a fast transactional storage.

History

First version of this article. Share it or discuss if you have any questions, tips or ideas.