Q & A. XII

Yesterday I was asked a weird question, and answer for that question deservers an individual blogpost 🙂

Q:

Hi,

I always try to follow up your posts and most of the times it just leaves me confused because some of the conclusions drawn here are contradictory from what EMC guides say. I was currently looking into an issue where the application throws “No more available sessions” error. One of the approach that I was thinking of suggesting was using session manager to release session instead of session.disconnect that we have seen caused some issues in the past for one of our applications. Can you throw some light on this?

Further, from what I see above – Is this always the recommended approach of getting session?
IDfSessionManager sMgr = client.newSessionManager();
Session = sMgr.getSession();

Do we have any particular scenario where private session is used using “IDfSessionManager.newSession()”?
A video from EMC architect that uses this code – https://www.youtube.com/watch?v=YjcxOfiiCNM

A:

This blogpost is not about “how to do Documentum routines”, it is about challenges which I have faced with and how I have managed those challenges, if you think that my opinion is inconsistent with EMC’s documentation/guides/white papers/etc you are always free to take advantage of your support contract and ask EMC why their documentation is a piece of shit, but don’t ask me about that – when I writing a blogpost I always trying to provide some code snippet to prove my opinion.

4 thoughts on “Q & A. XII

  1. With all due respect, I always liked the way you have provided the code snippet to prove your opinion. It’s just that I am still not a Documentum expert and some of the explanations may be well beyond my understanding. Offcourse, I still consider myself a learner and I was just hoping that I could learn something from you by asking few questions that always kept bothering me since EMC guides are the first things we look at when trying to build up/learn something new about Documentum.

    Like

  2. If you just started to learn Documentum it is a good idea to stop doing that – switch to anything else: EMC has neither vision nor strategy for Documentum, they unable to provide good support, they unable to write a clear documentation. All their documentation is obsolete, misleading and wrong. Let me provide some examples:

    getOriginalSession() returns the original session, getObjectSession() returns the object session, getSession() is provided for compatibility purposes and returns the original session. How is it possible that getSession() is equivalent to getObjectSession()? I do know the answer: it does not matter what method you are using if you are dealing with single repository only, but in case of multiple repositories 90% of DFC code is broken just because of misleading documentation. Moreover, don’t you think that if something is “provided for compatibility purposes” it must marked as deprecated?

    Another one:

    There is a cool call of userSessionMgr.clearIdentity(repository) which immediately disconnects all sessions derived from userSessionMgr. What do you think, is it an expected behaviour from “leaner” perspective or not?

    You are experiencing difficulties with session leaks, do you have any idea what is the root cause of your difficulties? During 10 years no one in EMC got an idea to mark IDfSession (and IDfCollection too) as java.io.Closeable, and now you are neither able to perform basic code checks (see http://help.eclipse.org/kepler/index.jsp?topic=/org.eclipse.jdt.doc.user/tasks/task-avoiding_resource_leaks.htm) nor able to use try-with-resources statement (https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html).

    Liked by 1 person

  3. Thank you for taking the time to respond to my question. It’s just that the more the number of whitepapers or documentations I was going through the more information crept in which lead me to dfc.session.max_count in dfc.properties to concurrent_sessions in server.ini to check if this can really help to avoid session leaks. Some of the answers mentioned what kind of error you can get, but there is no solution to prevent this. Some even claimed its an issue with session manager. From the code I was analyzing, it is just a simple web application that gets the object Id, searches in repository and returns the link to the document. Every month, we come across this “No more available sessions” error. The code it has doesn’t use session manager, instead it’s just trying to create a session and use session.disconnect in the end. After going through multiple channels, I thought implementing a session manager factory and releasing the session in finally block should fix the issue, but I was not confident if that will work.

    Fortunately, I landed up here where I am having discussion with you.

    P.S. I felt Documentum is very powerful as a content management tool with so much to learn that I can incorporate the concepts here to other content management systems as well. It has been a good journey so far and whenever I look at blogs by you or some other Documentum experts, I feel like this is what I need to understand and learn, the core concepts which can help me design the systems some day effectively 🙂

    Like

  4. Well, it is hard to say what do you mean under “the code it has doesn’t use session manager, instead it’s just trying to create a session and use session.disconnect in the end” because from DFC perspective there are no sessions which are not backed up by session manager, i.e. this code:

    IDfClientX clientX = new DfClientX();
    IDfClient client = clientX.getLocalClient();
    IDfLoginInfo loginInfo = clientX.getLoginInfo();
    loginInfo.setUser("username");
    loginInfo.setPassword("password");
    IDfSession session = null;
    try {
        session = client.newSession("docbase", loginInfo);
    
        // some logic
    
    } finally {
        if (session != null) {
            session.disconnect();
        }
    }
    

    is equivalent to:

    IDfClientX clientX = new DfClientX();
    IDfLoginInfo loginInfo = clientX.getLoginInfo();
    loginInfo.setUser("username");
    loginInfo.setPassword("password");
    IDfSession session = null;
    try {
        IDfSessionManager sessionManager = new SessionManager(
                RuntimeContext.getInstance().getSessionFactory(),
                RuntimeContext.getInstance().getSessionRegistry());
        sessionManager.setIdentity("docbase", loginInfo);
        session = sessionManager.getSession("docbase");
    
        // some logic
    
    } finally {
        if (session != null) {
            session.disconnect();
        }
    }
    

    and the code:

    IDfClientX clientX = new DfClientX();
    IDfClient client = clientX.getLocalClient();
    IDfLoginInfo loginInfo = clientX.getLoginInfo();
    loginInfo.setUser("username");
    loginInfo.setPassword("password");
    IDfSessionManager sessionManager = client.newSessionManager();
    sessionManager.setIdentity("docbase", loginInfo);
    IDfSession session = null;
    try {
        session = sessionManager.getSession("docbase");
    
        // some logic
    
    } finally {
        if (session != null) {
            sessionManager.release(session);
        }
    }
    

    is equivalent to:

    IDfClientX clientX = new DfClientX();
    IDfLoginInfo loginInfo = clientX.getLoginInfo();
    loginInfo.setUser("username");
    loginInfo.setPassword("password");
    IDfSessionManager sessionManager = new SessionManager(
            new PooledSessionFactory(new PrincipalAwareSessionFactory(
                    RuntimeContext.getInstance().getSessionFactory())),
            RuntimeContext.getInstance().getSessionRegistry());
    sessionManager.setIdentity("docbase", loginInfo);
    IDfSession session = null;
    try {
        session = sessionManager.getSession("docbase");
    
        // some logic
    
    } finally {
        if (session != null) {
            session.disconnect();
        }
    }
    

    I don’t see any difference which may cause resource leak, which means your suspicions about session.disconnect() call are wrong.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s