1. Via an environment idea, as in BerkeleyDB or in JDBC. So the properties have to be stored or association with user specific session environment. But then the user has to execute everything through the environment. For example, as opposed to just executing an Instant constructor a user would do the following.
tauZamanEnvironment env = CalendricSystem.startSession(...);
Instant myInstant = env.createInstant('January 2, 2002');
or passing the environment as a parameter
tauZamanEnvironment env = CalendricSystem.startSession(...);
Instant myInstant = Instant(env, 'January 2, 2002');
However, both of them needs user to deal with an extra parameter, env. We would like to do it in a way transparent to user.
2. Via a unique session ID idea. So, each user is registered with a unique session ID, which is hidden. And a particular CalendricSystem, which is registered by a user, can associate a session ID with a user and allocates an individual user space for individual Property operations. In user side, nothing is changed;
Instant myInstant = Instant('January 2, 2002');
Second approach is chosen to be implemented. Here is the details of client (user) /server interaction.
There are two different registration processes that can be performed in the system;
1. Each user, who wants to make use of the tauZaman system will register himself/herself to the system.
2. After registering the system, a user must perform subsequent registrations to be able to use a particular CalendricSystem service.
After registering to system, a unique session ID is produced for each different user and a Session is associated with it. Session contains all registration information for a user. After registering for a particular CalendricSystem, a user space, associated with generated unique session ID, for user-specific operations will be allocated in that CalendricSystem. A request to registration for a CalendricSystem may result in loading that particular CalendricSystem into system, if it does not already exist.
All services after registration processes are normal procedure calls and registration information is hidden. Although system has deregistering methods, which clears a user session from the system, as a principle, system can not trust user to deregister him/herself. So, it may periodically collect the garbage Sessions as well as CalendricSystems. This garbage collection may be implemented as a low-level thread, which applies two criteria as a formula;
1. A particular CalendricSystem, which is not associated with any session ID will be collected.
2. If timestamp of a user exceeds a limit, it will be deregistered implicitly. (with sending a message to user)
note: shallow and deep remove options will be used according to current load of the system.
See a detailed document about interactions between client/server.
See detailed designed API Specification about registration issues in CalendricSystemManager.
See design decisions on exceptions on registration process.