Echelon LNS - Manual (Page 79)

LNS Programmer's Guide 65
object are not available until the system has been opened. See the LNS Object Server
Reference help file for a complete list of the properties of the System object, and
descriptions of those properties.
Once you have opened the System object and set its parameters as you desire, you can
begin programming your application to perform monitor and control operations, or to
perform network management tasks. Echelon recommends that you review the rest of
this chapter before proceeding to these tasks.
Using Transactions and Sessions
LNS provides two ways to group sets of database modifications: transactions and
sessions.
Transactions allow a set of database and network modifications to be treated as an
atomic operation. This allows sequences of changes to be canceled on the network and in
the LNS databases if a failure occurs during any part of the sequence. You can also use
transactions to substantially speed up operations if you group multiple changes within a
single transaction. Unless operations must be kept separate or are not allowed within a
transaction, transactions should be used to optimize performance and allow for atomic
roll back of the operation sequence.
Sessions allow certain types of database and network modifications to be grouped and
executed together, without requiring verification that each property write and method
invocation was valid until all operations have completed. This allows your application to
create connections more efficiently, and to avoid failure scenarios that can occur when
devices or routers are moved or changed one step at a time.
Managing Transactions
Transactions can be explicitly managed by an LNS application using the transaction
methods provided by the LNS Object Server, or implicitly managed by the LNS Object
Server. If an application does not explicitly start a transaction, the LNS Object Server
automatically starts one when the LNS application invokes a method that causes a
database modification to two or more objects, and commits the transaction when the
service completes. This is called an implicit transaction.
Implicit transactions are easy to use because they are transparent to the application.
Explicit transactions are useful when you want to group multiple actions into a single
operation. For example, you may want to treat installing a device and connecting that
device to a set of other devices as one indivisible action. Or, you may want exclusive
access to the services you are performing. Only one client can use a transaction at a time.
Thus, if the user cancels part of a transaction prior to completion, the application can
cancel the entire transaction, returning the database to the same condition it was in
prior to the invocation of any of the services. Grouping several related actions as a
transaction improves performance in many cases, since device updates are not sent out
until the transaction is committed. The performance improvements caused by using
explicit transactions can be significant, so use them whenever possible, particularly if
you are creating multiple objects of any type or if you are iterating through a collection.
For more information on using transactions with collections, see the Using Transactions
With Collections section later in this chapter.