Archive for December, 2007
Q: “I’m not using transaction logging, why do I need to designate a Transaction Log Space?”
A: One virtual space in each disjoint set of virtual spaces used in an application must be designated as the location for the Transaction Log (flagged as ‘TL’ in the Control Panel), even if transaction logging is disabled, since transactions may include objects in any of that disjoint set which are connected to the image in which the transaction exists, and the TL space co-ordinates these. If transaction logging is disabled then any space may be designated as the TL space, even if it contains application domain objects. However if logging is enabled the TL space may contain only the Transaction Log; VOSS enforces this and any transaction which attempts to commit objects into the TL space will be forced to rollback if logging is enabled.
For full data integrity in the event of random power failures etc, logging should be enabled and a separate virtual space created and designated at TL space, preferably located on a different disk drive.
Logging is enabled like this:
VOManagers logging: true.
VOManagers is a global variable holding the sole instance of VOManagerManager.
All virtual spaces connected to an image share the same TransactionLog since a transaction may include objects in any connected virtual space.
Q: “I would like the development image to behave the same as the runtime, that is, non-interactive mode. How do I do this?”
A: Like this:
VOSS interactive: false.
Q: “I’m confused about image ids, names and logon/logoff.”
A: The name of an image is documentary only, and is set by VOSSServer>>imageName:.
The (default) ImageID is a random 6-digit integer assigned automatically (during VOSSRoot class>>initializeVOSS), identifies the image in system log messages written to <myspace>.log, and also may be used to control the number of concurrent images logged on to any virtual space.
Neither the ImageID nor ImageName are prompted for interactively on initialization of the runtime version of VOSS, only in the development version. The ImageName may be set at any time by
LocalVOSSServer imageName: aString.
or
LocalVOSSServer renameImage. “via a dialog box”
The name of a virtual space is its file pathname.
VOManager newForExistingSpace: ‘D:\vospaces\myspace’.
creates a new instance of VOManager which connects the image to the files and assumes that they exist; i.e. it will fail if they don’t all exist.
VOManager newWithFullPathName: ‘D:\vospaces\myspace’.
assumes they don’t exist and will fail if any of them does exist.
Connect/Disconnect means a VOManager which knows the file pathname is created/removed.
Log-on/Log-off means the VOManager opens/closes the files and registers its log-on/log-off in the virtual space by a system transaction, so there is a persistent log of which images logged-on/off and when.
Q: “As each image has an id, how does that work from a runtime image which might be installed on multiple PCs? Any special requirements for generating runtime?”
A: In a runtime image, the global variable ImageID is a random 6-digit number allocated when VOSS is initialized by the statement:
VOSSRoot initializeVOSS.
It’s used to control the number of concurrent images logged on to any virtual space, which is relevant only when VOSS is used in client/fileserver configuration, i.e. VOSS installed on the client machines, all connected to the same virtual space files. When VOSS is configured as a server, serving each remote client by a separate background process in the same image, imageID is relevant only in multi-processor servers, where each server cpu is running a separate image. There is a small chance that two images could be allocated the same ImageID, if this happens then the second to log-on will be told it is already logged-on. Re-initializing VOSS in that image will allocate another ImageID.
This can also happen after a crash where an attempt to log-on, although finding the virtual space in good condition, finds that the image is still recorded as logged-on, in this case it is automatically logged-off and the user is asked to log-on again; no re-initialization is necessary.
