Connecting .NET and IBM i with NTi
General considerations
Connection pool
NTi does not implement a connection pool. It's up to the user to implement it in .NET if necessary. In this way, the user has total control over the connections he opens and closes, without delegating this work to a randomly operating connection pool.
💡 It's easy to implement a custom object pool in .NET. For example, use this mechanism using
ConcurrentBag<T>to implement your own connection pool.
One instance = one TCP connection = one IBM i job
Each instance of NTiConnection carries a TCP socket instance to connect to the IBM i. Thus there is a strong link between the instance, the connection and the IBM i job.
When an instance of NTiConnection is explicitly destroyed via .NET's Garbage Collector, the underlying TCP connection is instantly closed and destroyed in turn, causing the IBM i job to stop. This mechanism guarantees total user control of connections.
Connection string
Like most database access providers, NTi uses a login string to obtain IBM i login information (username, password, etc.). This connection string may contain sensitive information. There are many ways to secure the management of the connection string and configuration files. Possible keywords for the NTi connection string are specified in the NTConnection property details below.
**Please refer to the official .NET documentation and recommendations for implementation.
ADO.NET implementation
This class implements the usual methods and properties of the ADO.NET model for database access operations:
Open()Close()CreateCommand()BeginTransaction()Commit()Rollback()- ...
In this way, NTi integrates into any existing application developed with other vendors, such as ODBC or OleDB drivers.
💡 Find documentation for this default implementation on any ADO.NET documentation, for example via the documentation of the
System.Data.Commonnamespace.
