Inside Documentum

I recently posted an article explaining how Content Server sessions work and the role of the client_session_timeout parameter (Understanding Documentum Sessions). In order to concentrate on the concepts that article dealt with a rather simplistic scenario, so I’d like to extend that discussion to look at how things change when you use the DF_EXEC_QUERY option when running a query.

Documentum has 2 basic query modes, a read-only mode and an exec mode. You can set these modes at the DFC level by including the DF_READ_QUERY or DF_EXEC_QUERY flags respectively. At the DMCL level this translates to one of the query apis like readquery, execquery or query_cmd. Some of these DMCL query APIs have a boolean parameter that allows selection of the mode but others like readquery only operate in one mode.

When you use read-only mode session behaviour is exactly the same as discussed in the article – the Content Server session thread runs the query using the established database session. However when you use exec mode Content Server will start a new database session to run the query. For the duration of the query there will be 2 database sessions associated with the Content Server session. In fact if you run additional queries at the same time in exec mode you get a new database session each time, so a single Content Server session could easily create 1+max_collection_count database sessions!

2 final points if you are using Oracle. First database sessions are an important resource that should carefully managed – make sure that you are using DF_EXEC_QUERY only when you need to. Second when you are trying to configure Oracle you may need to set the PROCESS parameter higher than the number of concurrent users as some of those users may be creating additional database sessions.