As noted earlier, the server API is wide and includes a large number of ArcObjects components that developers can use to include functionality in their application. This does put responsibility on the developer to build applications that do not allow the user of that application to put either the Web server (in the case of a Web application or Web service) or the database server in a state that results in a denial of service to other users.
Two key areas that will be discussed in detail are writing output and executing and evaluating the results of database queries.
The GeoDatabase library includes objects that allow you to query data in a database using spatial filters, attribute filters, or a combination of both. At this level of the ArcObjects API, no limits or constraints are put on the nature of the query or the number of records that may be returned by the cursor resulting from executing the query. If, for example, a Web application executes a query that returns 1,000,000 rows and iterates through each row, this can (depending on the nature of the query) tie up the database server while the query is evaluated, then tie up the Web server as the application iterates through the 1,000,000 rows.
These types of queries should be avoided by not allowing users to perform ad hoc queries against the database. Design your application to tightly control the types of queries that users can execute (or that are executed as a result of their interaction with the application). Also, set limits on the number of query results that the application will process for those cases where a large number of query results are returned from the database. You can do this by evaluating a fixed number of maximum rows from result cursors.
The following is an example of executing a query that may return a cursor with a large number of records. In this example, the application will stop evaluating the cursor after the first 100 rows have been retrieved. Assume that pFeatureClass is a feature class in the server context:
[code example to be provided]
Dim pQueryFilter As IQueryFilter = pServerContext.CreateObject("esriGeodatabase.QueryFilter")
pQueryFilter.WhereClause = "ObjectID > 100"
Dim pCursor As ICursor = pFeatureClass.Search(pQueryFilter, True)
Dim i As Long
i = 1
Dim pFeature As IFeature = pCursor.NextRow()
While Not pFeature Is Nothing And i < 100
' do something with the feature
i = i + 1
Set pFeature = pCursor.NextRow()
Wend
There are some cases when using the coarse-grained methods on the MapServer where queries can be executed, but the execution and evaluation of that query takes place in the MapServer. For example, the QueryFeatureData method on IMapServer returns a fully populated record set containing the results of the query. To ensure that these record sets do not contain a number of rows too large for the system to handle, the MapServer itself has built-in limits to evaluate the results of a query to a maximum record count (logically the same as demonstrated above).
This maximum is set as a property of the MapServer object itself called MaxRecordCount. By default, the MaxRecordCount is 500, but this property can be modified by the administrator of the GIS server by modifying the value of the MaxRecordCount XML tag in the MapServer's configuration file. For more information about the GIS server's configuration files and how to modify them, see Working with configuration files .
This maximum record count will be applied to the results of the following methods on IMapServer:
The MapServer also allows you to dynamically draw buffers around features by specifying a SelectionBufferDistanceProperty on ILayerDescription that is greater than zero. If the selection is large, this can greatly increase the resources required to draw a map. The MapServer also has built-in limits to limit the number of features that can be buffered per layer.
This maximum is set as a property of the MapServer object itself called MaxBufferCount. By default, the MaxBufferCount is 100, but this property can be modified by the administrator of the GIS server by modifying the value of the MaxBufferCount XML tag in the MapServer's configuration file. For more information about the GIS server's configuration files and how to modify them, see the Working with configuration files topic.
The GeocodeServer also has built-in limits that prevent requests from returning results that are too large. Specifically, the number of records returned by the FindAddressCandidates method is limited by the GeocodeServer's MaxResultSize property. The default for this is 500, but this property can be modified by the administrator of the GIS server by modifying the value of the MaxResultSize XML tag in the GeocodeServer's configuration file. For more information about the GIS server's configuration files and how to modify them, see the Working with configuration files topic.
The GeocodeServer also has a built-in limit for the number of input records that can be passed into the GeocodeAddresses method. This maximum is set as a property of the GeocodeServer itself called MaxBatchSize and can be modified by the administrator of the GIS server by modifying the value of the MaxBatchSize XML tag in the GeocodeServer's configuration file.
Another area where application developers need to be careful is when their applications write output to a server directory. Files that are large may take a large amount of disk space and a large amount of resources to produce. Developers will have to limit the size of files they write with these considerations in mind.
The MapServer's ExportMapImage method takes an ImageDescription object that includes the size of image requested. To limit the size of images produced by ExportMapImage, the MapServer has built-in limits for the size of images that ExportMapImage will produce.
This maximum is set as two properties of the MapServer object itself called MaxImageWidth
and MaxImageHeight, specified in pixels. By default, these are set
to 2048, but these properties can be modified by the administrator of the GIS
server by modifying the values of the MaxImageWidth and MaxImageHeight
XML tags in the MapServer's configuration file. For more information about the
GIS server's configuration files and how to modify them, see the
Working with configuration files topic.