Node Persistence

(Redirected from Persistent nodes)
Jump to: navigation, search


Node Persistence defines whether or not a node is saved (persisted) to the database.


A node in the SERVER GOM is either "persistent" or "non-persistent". Client nodes are never persistent. See HSL FAQ.

Persistent nodes are used when a node, and the node's state, need to be remembered beyond the current session. When an Area Server shuts down, all non-persistent nodes are simply discarded and their existence is never saved in the database. Persistent nodes are (under the right circumstances, see below) saved in the database whenever they change, and removed from the database when they are deleted.

Changes to the GOM are only persisted to the database under the following circumstances:

  1. Persistent Node - Only nodes created as persistent are persisted in the database.
  2. One or More Member Fields are "Dirty": - Nodes are persisted to the database when they are marked dirty by virtue of modifying one or more fields with whose DOM definitions declare write strategies other than never or explicit.
  3. Root Node Changes - Persistent nodes must be associated to a root node in order for HeroScript to load them from the database. Persistent nodes that are not root nodes themselves or associated via a hard association to a root node are "orphaned" in the database and must be purged via a SQL statement via a periodic maintenance cycle.
    1. Character Changes - A change was made to a GOM node associated to a character root node (the character root node, an inventory item, etc.). These changes are persisted to the database at regular intervals, or when the character leaves an Area (moving to a new one, or logging off).
    2. Account Changes - A change was made to a GOM node associated to an account root node (the account root or persistent objects associated to it).
    3. Area Changes (Edit Instance Only) - Changes made to GOM nodes associated with an area root node are only persisted if two conditions are true: (1) the change occured in the special Edit instance of an Area (of which there is only one per Area: instance# 0). (2) That the node was created to be persistent. Even in edit instances, there may exist many nodes which are temporary and not persisted. Changes made in other non-edit instances of an Area are not persisted to the database ever. The edit instances are usually only accessible in the Development Server Universe(s) (with updates published to the live game via Live Update or World Push). An exception to this rule though, is certain types System Areas (services) which may be run as edit instances on the Production Server, in order to keep persistent copies of certain types of information (such as guild membership).
    4. Generic Root Nodes - function as special entities allowing alternative node hierarchies to be persisted (other than the basic root node types; accounts, areas, and characters) and loaded from the database by HeroScript.
  4. Prototype Changes - Changes to the prototypes are persisted to the database, and these changes are also reflected to all active areas when they occur (this update happens within a few seconds). Again, only the Development Server Universe allows this.

Note: Theoretically, any node can be created to be persistent; however, any persistent node is almost certainly going to have to be in one of the above hierarchies, otherwise it runs the risk of not being saved properly to the database, and being left as an "orphaned" node.

Functions related to Persistence

 IsPersistentNode(node as NodeRef) as Boolean
 CreatePersistedNodeFromClass(className as String)as NodeRef
 CreatePersistedNodeFromNode(node as NodeRef) as NodeRef
 CreatePersistedNodeFromPrototype(prototypeName as String) as NodeRef

Related CLI Commands

These CLI commands have an optional flag to specify whether the created node is persistent or not

Additional Information

Personal tools