Echelon LNS - Manual (Page 334)

LNS Programmer's Guide 320
NOTE: LNS uses an optimized memory allocator that manages its own local heap. This
allocator holds most memory that it allocates for future re-use. Therefore, early in an
application's run-time, memory usage may continually climb. However, it will eventually
reach a point of stabilization. At this point, the memory allocator will have enough
memory in its pool so that it does not need to request more memory from the system.
Memory freed internally is kept by the allocator, and then re-used.
Debugging LNS Applications
This section describes a few considerations you should make when debugging an LNS
application. If a transaction is interrupted prior to completion for any reason, the LNS
databases and the network are returned to their states prior to the start of the
transaction. If an application starts a transaction, then it should commit or cancel the
transaction within a reasonable time to avoid hanging other applications. No other
applications can start a new transaction until the current one is committed or cancelled.
While a transaction is in progress, LNS automatically queues requests to start either
additional implicit or explicit transactions. If an application shuts down while it has an
outstanding transaction, and another application attempts to start a transaction, the
LNS Object Server will cancel the abandoned transaction within 30 seconds. Once a
transaction is committed or canceled, other transactions on the system can begin.
This behavior can cause problems when debugging your application. For example, LNS
may cancel a transaction because your application has started a transaction and is
halted in a breakpoint. You can disable this behavior by setting the following Windows
Registry DWORD entry to a non-zero value:
HKEY_LOCAL_MACHINE\SOFTWARE\LonWorks\NSS\Configuration\Transaction
Debugging
Set its value to 0 (zero), or remove the entry, to disable the transaction debugging mode.
You should only modify this Windows Registry entry for debugging purposes, since
disabling this feature may cause all LNS clients to lock up if the value is changed, and an
application running a transaction is improperly terminated. For more information on
transactions, see Using Transactions and Sessions on page 65.
You should also note that if your LNS application is abnormally terminated (due to a
crash or terminated by the debugger), there are some LNS processes that may be left
running. A few examples are NSSENG.EXE, LCAMON.EXE, and PTSERV.EXE. It could
take some of these processes up to one minute to finish after the application abnormally
terminates. Restarting your application before these processes have had a chance to
shutdown may cause your application to crash or hang. However, Echelon recommends
that you do not terminate these processes manually. You should allow them to finish
whenever possible. Note that you may have to reboot your PC in case a subsequent start
of your LNS application fails.
LNS and Line-Safe Expressions
Programmers sometimes combine several expressions in one line of code, as opposed to
explicitly assigning one object variable and performing one method invocation for each
part of an operation. For example, to fetch an AppDevice object named “Buzzer” from a
Subsystem object with the subsystem path “Shared Devices.Alarms”, starting from a
given System object, the step-by-step approach is as follows: