Structural Overview

Figure 1 depicts the over-all structural view of Calendar related part of tauZaman.

Abbreviations:

First don't care about red arrows. Relations can be well understood by only concentrating on black lines.

                                                                                                                Figure 1

The only problem seems is garbage collecting. Now (concentrating on red lines) if a user removes its TZS, by distributed garbage collection (of JAVA RMI) we get rid of TZS and also all red lines. However, still there are black lines, which pointing to what red lines pointing. That means we can't use JVM's garbage collector. We might employ our garbage collector (a low priority thread, runs once in a while) checking references we impose on objects. However, we can't impose references on objects, since, for example, a user may push same Property twice, and we increment its referenceCount twice, which is not right (we have to get user identity -session ID-, which we wanted to get rid of).

Now, let's think that we have our own garbage collector, which looks at statistical information in objects (CalendricSystems, FVSupports, Property(ies)) and removes them. This information will include their first loading and last reference timestamps. As opposed to above paragraph, if we remove the black lines, which our garbage collector will do, we still have the red lines. However, once red lines go away, which means user quits, then JVM's garbage collector can do its job. So, as long as some user referencing an object, our garbage collector will not create a null reference problem.