Oracle Web Services On Demand Guide > Establishing and Managing the Web Services Session >

Comparison of Stateless Versus Stateful Web Services Transactions

Stateful Web services are generally used when querying a large number of records or performing bulk data operations, for example uploading large volumes of data. Some characteristics of stateful Web services transactions include:

• Do not utilize OM session pooling (the client application must manage the session for each request)
• Return a valid JSESSIONID value, which is used for authenticating subsequent requests
• An OM session is not shared and can store details about previous requests, this is helpful when performing pagination over a query result set. The session will not be used by other applications as the session ID must be explicitly specified in the requests.
• The session limit quota controls the number of sessions that can be established for a company.

In general, it is recommended that customers use stateless Web services for several important reasons:

• Stateless Web services provide more efficient resource utilization for most uses.
• Stateless Web services do not impact the session limit quota.
• Since customers are responsible for Web service development, stateless Web services can dramatically reduce complexity and cost of developing new integrations as resource management is performed by Oracle. For stateful Web services, this is the customer's responsibility. For example, customers do not need to code logic to log off following a stateless request/response.
• Stateless Web service requests achieve a higher level of concurrency because Oracle CRM On Demand code manages sessions.
• Additional error handling logic is also the customer's responsibility and must be implemented correctly with stateful Web services.

Customers must ensure stateless Web services are used for short, interactive requests where high concurrency is required.

Some characteristics of stateless Web services transactions include the following:

• Support OM session pooling. Sessions are managed and pooled internally by the Oracle CRM On Demand server.
• Perform a logoff (invalidation of the Java session) after processing each request unless the <SessionKeepAlive> parameter is set to true. The client application does not have to manually submit a request to log off a session.
• Return a JSESSIONID value to help maintain server affinity (that is, direct subsequent requests to the same Java server), if the <SessionKeepAlive> parameter is set to true in the request.

Stateless Web services transactions must be used for Administrative Services APIs. A full login is performed for each request.