Pitney Bowes MapXtreme - Manual (Page 517)

Appendix D: Extensible Data Providers
Advanced Topics / Important Considerations
MapXtreme v7.1 524 Developer Guide
}
catch (Exception e)
{
cbinfo = new DataProviderCallbackExceptionInfo(e);
}
if (ds == null
&& callbacks != null)
{
while (!needDS
&& callbacks.MoveNext())
{
// callback will return null if it is unable to modify the
// the definition appropriate for a retry attempt
// Example: User selected cancel from a credential input dialog
tmpDsDef = callbacks.Current.Callback(dsDef, cbinfo) as
EDPDataSourceDefinition;
if (tmpDsDef != null)
{
needDS = true;
}
} // while (!needDS and callbacks.MoveNext())
} // if (ds == null && callbacks != null)
if (!needDS
&& cbinfo != null)
{
throw cbinfo.Exception;
}
} // while(needDS)
return ds;
}
Thread safety
MapXtreme is thread safe meaning that different threads may concurrently be accessing different
sessions, catalogs, tables, maps, etc. without any unintended side-effects. MapXtreme objects are
not multi-threaded meaning that the same instance of a map, table, catalog, etc. cannot be
accessed from multiple threads at the same time. Data provider implementations must at least follow
this model if there is ever an expectation that the data provider will be deployed in a web
environment.
Generally your code should be thread safe as long as you do not rely on any global variables,
singleton objects, etc. You should also not rely on use of Thread Local Storage since ASP.NET may
actually cause the executing thread of your request to change. If your data provider follows these
guidelines, you should not require much, if any, synchronization locks throughout your code which
may choke the scalability of the solution. The actual data that you are accessing, however, may
have implied synchronization that is either unavoidable or preferred. For example, if your data
provider exposes data from an Excel spreadsheet, the spreadsheet may be locked from editing