-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 
Author Message
 Post subject: HibernateSessionFactory
PostPosted: Mon Apr 18, 2005 7:12 am 
Regular
Regular

Joined: Tue Nov 23, 2004 7:42 am
Posts: 82
Location: London, England
We have tried to different HibernateSessionFactory implementations.

This is the first:
Code:
public class HibernateSessionFactory {

    private static final Logger logger = Logger.getLogger(HibernateSessionFactory.class);
    private SessionFactory sessionFactory;
    private static HibernateSessionFactory _instance = null;
    private static int counter = 0;
   
    /**
     * Session is a thread local so that each thread has its own copy
     */
    public static final ThreadLocal session = new ThreadLocal();
   
    /**
     * Hidden constructor
     */
    private HibernateSessionFactory() {
        super();
       
        try {

            // Create the SessionFactory
            //
            sessionFactory = new Configuration().configure().buildSessionFactory();

        } catch (HibernateException ex) {
           
            // something went wrong. Rethrow and catch
            //
            logger.fatal(ErrorCodes.getString(ErrorCodes.DB_ERROR_SESSION_CREATE), ex);
            throw new RuntimeException(ErrorCodes.getString(ErrorCodes.DB_ERROR_SESSION_CREATE), ex);

        }
       
    }


    /**
     * Returnt the only instance of this session factory
     *
     * @return Session factory
     */
    public static HibernateSessionFactory getInstance() {

        if (_instance == null) {
            _instance = new HibernateSessionFactory();
            counter += 1;
            return _instance;
        } else {
            return _instance;
        }
    }


    /**
     * Obtain a hibernate session
     *
     * @return A valid a Hibernate session
     * @throws HibernateException
     */
    public Session getSession() throws HibernateException {

        // try to get a valid session
        //
        Session s = (Session) session.get();

        // Open a new Session, if this Thread has none yet
        //
        if (s == null) {

            // lets get a new session
            //
            s = sessionFactory.openSession();

            session.set(s);
        }

        // return an active session
        //
        return s;
    }

    /**
     * Disconnect and close a session
     *
     * @throws HibernateException
     */
    public void closeSession() throws HibernateException {
       
        // extract the local session
        //
        Session s = (Session) session.get();
        session.set(null);

        if (s != null) {
           
            // notify the session that the transaction completed, so we no
            // longer own the old locks. (Also we should release cache softlocks.)
            // may be called multiple times during the transaction completion process.
            // calling disconnect on the session has the effect of calling
            // afterTransactionComplete(true);
            //
            s.disconnect();
           
            // close the session
            //
            s.close();
        }
    }

}


This is the current one, similar to that from the docs:
Code:
public class HibernateSessionFactory {

    private static final Logger logger = Logger.getLogger(HibernateSessionFactory.class);
    private static SessionFactory sessionFactory;
   
    /**
     * Session is a thread local so that each thread has its own copy
     */
    public static final ThreadLocal session = new ThreadLocal();
   
    static {
        try {
            // Create the SessionFactory
            sessionFactory = new Configuration().configure().buildSessionFactory();
        } catch (Throwable ex) {
            logger.error("Initial SessionFactory creation failed.", ex);
            throw new ExceptionInInitializerError(ex);
        }
    }

       
    /**
     * Obtain a hibernate session
     *
     * @return A valid a Hibernate session
     * @throws HibernateException
     */
    public static Session getSession() throws HibernateException {

        // try to get a valid session
        //
        Session s = (Session) session.get();

        // Open a new Session, if this Thread has none yet
        //
        if (s == null) {

            // lets get a new session
            //
            s = sessionFactory.openSession();

            session.set(s);
        }

        // return an active session
        //
        return s;
    }

    /**
     * Disconnect and close a session
     *
     * @throws HibernateException
     */
    public static void closeSession() throws HibernateException {
       
        // extract the local session
        //
        Session s = (Session) session.get();
        if (s != null) {
           
            // Completely clear the session. Evict all loaded instances
            // and cancel all pending saves, updates and deletions.
            // Do not close open iterators or instances of
            // ScrollableResults
            //
            s.clear();
           
            // notify the session that the transaction completed, so we no
            // longer own the old locks. (Also we should release cache softlocks.)
            // may be called multiple times during the transaction completion process.
            // calling disconnect on the session has the effect of calling
            // afterTransactionComplete(true);
            //
            s.disconnect();
           
            // close the session
            //
            s.close();
        }
       
        session.set(null);
    }

}


We have found that with our own implementation memory usage would creep up over time and not come down, yet this wasn't the case with the 2nd implementation. Obviously there are differences - most notably the static methods.

Can anyone make any comments on which method is better and why?

rgds,

Rilux


Top
 Profile  
 
 Post subject: memory problems
PostPosted: Mon Apr 18, 2005 9:05 am 
Newbie

Joined: Mon Apr 18, 2005 4:22 am
Posts: 2
I am most interrested in this issue too. But it seems that for me, both the first and second strategies give me memory leaks.
I have made two test methods in the EJB, one for each Session factory strategy. The client would call each of these methods like ten times, and I can notice a few KB of memory leakage for each test. I guess the amount of memory depends on the amount of classes that are mapping the tables.

I believe this happens because there are still locks from the sessionfactory (I believe this because I have worked on a project that works with more databases, so it dynamically changes the current one).

I would appreciate any more discussion on the matter, or sollutions :)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 18, 2005 9:56 am 
Beginner
Beginner

Joined: Wed Apr 13, 2005 12:49 pm
Posts: 34
Hi folks,

What profiler are you using for to detect the leaks? In the past when
I've encountered mem leak problems I've resolved them by remote
debugging with Eclipse Eclipse while profiling with JProfiler.

http://www.ej-technologies.com/download ... /trial.php

If you let it run for a while and then take a snapshot it tells you in descending
order the number of objects instantiated of each class and you can also drill
down to the line of code where the objects were created from.

I'm guessing you may know all this but just in case.

Thanks,
Mark.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 18, 2005 9:58 am 
Regular
Regular

Joined: Tue Nov 23, 2004 7:42 am
Posts: 82
Location: London, England
gags_78 wrote:
Hi folks,

What profiler are you using for to detect the leaks? In the past when
I've encountered mem leak problems I've resolved them by remote
debugging with Eclipse Eclipse while profiling with JProfiler.

http://www.ej-technologies.com/download ... /trial.php

If you let it run for a while and then take a snapshot it tells you in descending
order the number of objects instantiated of each class and you can also drill
down to the line of code where the objects were created from.

I'm guessing you may know all this but just in case.

Thanks,
Mark.


We bought this a couple of months ago. We're profiling with major loads as we speak.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 18, 2005 10:16 am 
Beginner
Beginner

Joined: Wed Apr 13, 2005 12:49 pm
Posts: 34
I guess that means that with major loads, creating snapshots would mean
grind the profiling machine to a halt?

Mark.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 18, 2005 10:32 am 
Newbie

Joined: Tue Apr 12, 2005 12:01 pm
Posts: 10
Location: London, UK
gags_78 wrote:
I guess that means that with major loads, creating snapshots would mean
grind the profiling machine to a halt?

Mark.


Hi all,

We have JProfiler - bought it a month or so ago. Something I have nver quite figured out is why the hep size gradually increase. We have checked most things but haven't found anything untoward in the heap. Number of classes always stay the same while the heap gradually gets bigger. Just can't figure out whats going on. The second implementation of the HibernateSessionFactory (first message of the thread) seems to be a lot better although it doesn't eradicate the problem completely.

_________________
Many thanks...
Arup


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.