Hello all,
is it possible to read values specified in server.ini file programmatically? For example, how to read the value for client_session_timeout, either by DFC, DQL or IAPI?
Thank you in advance, Predrag
If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.
Most (if not all) of the settings reflected in server.ini are actually reflected in the dm_server_config object. This persistent object can be accessed via DFC, DQL etc.
Hi Stojkovic,
I have not tried this. But I think, we can do this by simple file reading technique line by line. we can split the by "=" and match the first part with the attribute name, in your case it is client_session_timeout and the second part will be desired value.
Thank you for the reply, @Layeeque_Md.
Reading from server.ini file would be fairly easy, since it is organized as classical properties file. However, the issue in this case is that server.ini file is generally not accessible from other servers, for example from an application server in the system.
That's why it would be better if it would be possible to fetch the values specified in that file by any of Documentum's APIs, like DFC. It would be possible if properties from server.ini were mapped to attributes of some repository object, like dm_server_config, or some class/interface in DFC.
I dont believe all of settings in the server.ini are exposed via DFC. I would log a ticket with support to find out for sure.
@Koeppster said: Most (if not all) of the settings reflected in server.ini are actually reflected in the dm_server_config object. This persistent object can be accessed via DFC, DQL etc.
That is true. However, to what attribute in dm_server_config is property client_session_timeout mapped?
To me, the only similar attribute is login_ticket_timeout, which is also expressed in minutes, but I can't find any reference in documentation to support that claim.
If you know the attribute, you should be able to test this easily. Make change in the server.ini and restart the CS for the new value to take place, then query for the attribute against dm_server_config .
login_ticket_timeout has nothing to do with client_session_timeout. As you correctly stated, not all properties from server.ini are exposed, in fact it looks like most properties are not exposed because they only matter to the server. Just out of curiosity, why do you need to know the value of client_session_timeout? The main purpose of this parameter is to free resources on the server for sessions who have no activity for more than n minutes. If after the timeout, the session issues a request, the session is automatically reestablished by the server. So you shouldn't really have to care about that.
@bacham3 said: Just out of curiosity, why do you need to know the value of client_session_timeout? The main purpose of this parameter is to free resources on the server for sessions who have no activity for more than n minutes. If after the timeout, the session issues a request, the session is automatically reestablished by the server. So you shouldn't really have to care about that.
The root of the question lays in session management. As stated in one of the official whitepapers, there is no positive way to know whether a session is alive or not:
Currently there is no way to tell if a DFC session is active or if the session expired. Even though the current session expires by the server, new session shall be created if the DFC application tries to query using the original session identifier (q0, q1 etc). IDfSession.isConnected method returns always true whether the session is alive or timed out unless the session is disconnected by IDfSession.disconnect().
Currently there is no way to tell if a DFC session is active or if the session expired. Even though the current session expires by the server, new session shall be created if the DFC application tries to query using the original session identifier (q0, q1 etc).
IDfSession.isConnected method returns always true whether the session is alive or timed out unless the session is disconnected by IDfSession.disconnect().
As it proved in our practice so far, obtaining new sessions is a bit slow operation - for example, if it takes only half of second or full second, and if it's needed to process 50K of operations/queries/etc. for probably different users, it would cost half an hour or full hour just for obtaining sessions. That's why we wanted to internally cache sessions and replace them with new ones only if there is a suspicion that they are expired.
If there's some ideas on that matter, I would also appreciate them (though it would probably be better to start a new discussion).
How are you obtaining your sessions? If you use SessionManager class, it uses its own session pooling, so that you dont have to do it yourself.
@PStojkovic , If you are more interested to use existing session, then we can remember, there are two method to get the session object: sessionMgr.getSession() //will provide you session from pool if there is any free else will create a new sessionMgr.newSession() //create a new session
