CORBA 2.3.3 Programmer's Guide for C++ (NonStop CORBA 2.3.3+)
Table Of Contents
- CORBA 2.3.3 Programmer's Guide for C++
- Legal Notice
- Contents
- About This Guide
- Chapter 1. Introduction to NonStop CORBA Programming
- Chapter 2. NonStop CORBA Administrative Environment
- Chapter 3. Compiling and Building an Application
- Chapter 4. Deploying a NonStop CORBA Application
- Chapter 5. Tracing and Debugging Applications
- Chapter 6. Writing Scalable Applications
- Chapter 7. Managing Transactions
- Chapter 8. Writing Multithreaded Applications
- Chapter 9. Designing Advanced Applications
- Chapter 10. Porting CORBA Applications to NonStop CORBA
- Chapter 11. Writing Wrappers for Legacy Clients and Servers
- Appendix A. Architectural Walkthrough
- Appendix B. Object References
- Appendix C. Servant Reference Counting in NonStop CORBA
- Index
NSOTS and TMF communicate through a pseudo-file called a recoverable resource manager (RM) file.
They exchange signals through this file using the TMF APIs. These signals are used to start and
terminate transactions. The RM file is also used during the initialization of NSOTS to recover any
in-doubt transactions following a failure.
The operations tmf_start and tmf_end are added to the CosTransactions::Current
interface to control the participation of NSOTS in outstanding TMF transactions.
When an exception is initiated by TMF, NSOTS assigns the TMF error code to the CORBA exception
minor code.
Transaction Service Features Not Supported in
NonStop CORBA
The following features of the Transaction Service are not supported by NSOTS:
Nested transactions●
Transactional dynamic invocation interface (DII) deferred synchronous requests●
TransactionFactory interface (you should design applications to use the
CosTransactions::Current interface)
●
Explicit propagation of transactions●
TransactionalObject Interface
An application-defined interface that inherits from the TransactionalObject interface indicates
that any transactional context associated with the client thread should be associated with operations on
the object's interface.
Note
In the OMG Transaction Service version 1.2, use of the TransactionalObject interface is
deprecated in favor of POA policies.
Checked Transaction Behavior
In performing checked execution for transactions, NSOTS attempts to enforce the rule that only one
thread may remain active in a transaction at termination. This means that all other threads must have
suspended and that any references to Control, Coordinator, and Terminator object
implementations must have been released. Without these checks, some application work might not
actually complete within the transaction's boundaries, or a memory leak of object references might go
undetected.
If an attempt is made to terminate a transaction when its reference count indicates that another thread