DFC session cache to prevent connection delays

cquesa

We have a library from DFC to insert documents in Content Server, among other functions.

Documentum connection through DFC takes about 3 seconds.

For this reason, we keep the connection permantent for optimization reasons.

Is there any way to specify it in dfc.properties? Configure session cache for preventing connection delays?

Currently, we keep a global DfSessionManager reference in memory once connected.

Server Version: 6.0.0.215 Linux.Oracle

Find more posts tagged with

Comments

christopher.imes

Please consider moving this question as-is (no need to recreate) to the proper forum for maximum visibility. Questions written to the users' own "Discussions" space don't get the same amount of attention and can go unanswered for a long time.

You can do so by selecting "Move" under ACTIONS along the upper-right. Then search for: "Documentum" and select the very first result that comes up. This will relocate it to the Developer Network subspace of the Documentum community.

For further guidance on engaging with the communities for Documentum and related products, please refer to the

IIG Communities Getting Started Guide.

PanfilovAB


Documentum connection through DFC takes about 7 seconds.

Before inventing another bicycle you should investigate why you get so long times.

cquesa

Sorry, you are right.

It takes about 3 seconds. Just measured.

PanfilovAB

3 seconds is too long too, for example I'm living in Australia and my dev environment is located in Dutch, and it takes 1 second to create session just because of slow internet connection. Anyway, DFC already caches connections internally you only need do not modify default settings like dfc.session.pool.enable and dfc.session.pool.mode and release session properly, check these topics: ,

cquesa

Connections are released once used in our library.

It seems StaticSessionManager is the best option.

It allows more connections per second, so it seems faster.

Even if dfc.session.pool.enable and dfc.session.pool.mode of level2, it takes some time each instantiation of SessionManager.

But using static SessionManager is not thread-safe, and our library is writing documents and will be highly hit

I think one option is use dfc.session.pool.enable and dfc.session.pool.mode of level2, and not storing a global instance of SessionManager because of thread-safe risk.

Our library uses a global instance of SessionManager, no pool, getSession for each request and release it in the end. SessionManager instantiation delays are prevented and thread-safe risk is solved because any sessions aren't cached.

Am I right?

PanfilovAB

The best implementation depends on what are you doing in your application:

if your application in a web application the best option is to store sessionmanager in httpsession, so you will get one sessionmanager per logged-in user
if you have some multi-thread loader and manages threads by yourself you can store sessionmanager in ThreadLocal, so you will get one sessionmanager per thread without need to pass it as argument
may be it's a good idea to switch to dfc 6.7sp2/7.0 and use global_pool_enabled=true

but if connection handshake takes 3 seconds, it's really a problem either in environment or code. If you dfc.properties has default parameters (i.e. dfc.session.pool.enable=true, dfc.session.pool.mode=level2) connection time should me measured in milliseconds, not seconds. I think you should check following things:

audit settings - if you auditing dm_connect event every successful login causes write to audit and you get database bottleneck
dm_user settings - when user logins content server updates last_login_utc_time field for corresponding user, so if you are using the same user in all your threads it can cause a database bottleneck, you can disable this feature by setting last_login_utc_time to nulldate (check this topic: )
if you creating session manager for every transaction check if you call clearIdentity() method

cquesa

Connections are immediate.

3 seconds is SessionManager creation delay. This instance is stored globally, as in option StaticSessionManager.

dfc 6.7sp2/7.0 and use global_pool_enabled=true is compatible with CS 6.0????

We are now testing CS6.7 SP2 and enterprise migration is forecoming.

PanfilovAB


Connections are immediate.

3 seconds is SessionManager creation delay.

It's even more strange, how do you construct it?


 dfc 6.7sp2/7.0 and use global_pool_enabled=true is compatible with CS 6.0????

"Not officially supported" does not mean "does not work".

cquesa

This class manages SessionManager global instance.

It is created once and reused

public class ManagerSesion {

protected static IDfSessionManager sessionManager;

public static IDfSessionManager getSessionManager() {

return sessionManager;

}

public static void setSessionManager(IDfSessionManager sessionManager) {

ManagerSesion.sessionManager = sessionManager;

}

static{

try {

IDfClientX clientx = new DfClientX();

IDfClient client = clientx.getLocalClient();

// create a Session Manager object

sessionManager = client.newSessionManager();

// create an IDfLoginInfo object

IDfLoginInfo loginInfo = clientx.getLoginInfo();

loginInfo.setUser(ConstantesADOC.DCTM_USER);

loginInfo.setPassword(ConstantesADOC.DCTM_PASS);

loginInfo.setDomain(null);

// bind the Session Manager to the login info

sessionManager.setIdentity(ConstantesADOC.DCTM_DOCBASE, loginInfo);

} catch (Exception e) {

e.printStackTrace();

}

PanfilovAB

I can't understand what is your problem now. If you are using static instance of sessionmanager and it's instantiation takes 3 seconds why it's a problem if you instantiating it only one time per application run? The only thing you can improve in this case is set dfc.verify_registration to false, it will skip dfc client registration during first instantiation of DfClient.

Oops. I missed you question:

Our library uses a global instance of SessionManager, no pool, getSession for each request and release it in the end. SessionManager instantiation delays are prevented and thread-safe risk is solved because any sessions aren't cached.

Using static/global sessionmanager does cause problems, because getSession() call returns the same session object for multiple threads and if you get the same session for multiple threads your threads will be blocked if one executes some long operations. The best practice is do not share sessionmanager among multiple threads.