Recent Changes - Search:

About

Users

Developers

edit SideBar

DesignOverview

This diagram depicts the over-all structural view of Calendar related part of tauZaman.

Abbreviations:

TZS TauZamanSystem
TZService TauZamanService (remote/local)
CSR Calendric System Repository
CS Calendric System
CR Calendar Repository
C Calendar
PR Property Repository
P Property
PM Property Manager
PSS Property Stack Service
FVR Field Value Repository
FVS Field Value Service
FVT Field Value Table
FVF Field Value Function

Relations can be well understood by only concentrating on black lines.

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.

Edit - History - Print - Recent Changes - Search
Page last modified on April 17, 2009, at 07:56 AM