Pitney Bowes MapXtreme - Manual (Page 518)

Appendix D: Extensible Data Providers
Advanced Topics / Important Considerations
MapXtreme v7.1 525 Developer Guide
operations while it is open for read operations in a different thread (or different process altogether).
For these scenarios, it is important to consider how you architect your data provider. Cursors,
feature accessors, and modify processors are all intended to imply a certain type of locking to the
data where that may be required. However, if there are no active cursors, accessors, or modify
processors, the underlying data files (if applicable) should not be held open.
The IDataProvider is the one exception where we actually recommend that you implement this as a
singleton. This interface is intended to be a factory interface and should not contain any state at all
(meaning no class member variables other than the static INSTANCE property). The definition
objects must reference their data provider for MapXtreme to be able to call into it to open a data
source or a table. For this mechanism, an instantiable class is required although a singleton is
perfectly suitable.
You may be inclined to want to cache connections and possibly even cache your datasource or table
objects and reuse them when calls to OpenTable or OpenDataSource. We strongly recommend that
you do not do this. MapXtreme provides collections for data sources and tables on the Catalog and
will rely on the Equals logic that you supply in your ITableDefinition and IDataSourceDefinition
classes to find and reuse the correct instances. This will prevent you from running into cross-thread,
multi-threaded situations. Your underlying data access technology, such as an ADO.NET data
provider, may cache and reuse data base connections. This is an acceptable architecture since they
assure the proper behavior in a multi-threaded environment.