also allows for more possibilities in configuration management. The developer may initiate several transactions from within a trans- action and demand that the transactions be carried out in a particular sequence. Indeed, some of the nested transactions may be executed concurrently. Further, transactions invoked from within a transaction may fail independently of their invoking transaction and independently of one another. This allows alternative transactions to be used in the event that one of the alternatives fail. Thus nested transactions are the basis for a general-purpose reliable programming environment in which transactions are freely composable modules. OSS for Telecom Networks In a nested transaction, an inner transaction can be committed only by the oper- ation which initiated it and then the outermost commit takes effect. If an exception or timeout occurs in the inner levels of a transaction, then the entire transaction is rolled back. When an exception occurs at any point, it must be handled such that it is propagated to the highest level transaction. User-defined objects or custom objects can be stored to, or retrieved from, the database even if they do not implement the main database API and do not extend the ManagedObject class. The UserStorage API can be used to add, delete, update and get UserObjects to and from the database. Since the methods are built around the data- base operations, this enhances the usability of the API. When the server is started, the UserStorage API can be accessed remotely via RMI or from the same JVM. 11.2.11.5 Severity Levels Severity is the measure or metric of criticality used in the product to handle net- work management occurrences. CMS makes heavy use of severities in most of its primary management functionalities. To give an idea of the pervasiveness of sever- ities, they are used to assign criticality to an event or alert and to show the status of a managed object or map symbol. Given the nature and importance of severities, it is natural to allow developers to c