• Post Reply Bookmark Topic Watch Topic
  • New Topic

DAO (Data Access Object) as a Singleton - will objects created get garbage collected?  RSS feed

 
Eric Fillman
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We recently started using the DAO pattern to create classes used to retreive data from Oracle.

We have a DAOFactory which is called to get a particular DAO class, which is really just an interface for an ORImpl class that accesses the database and gets the data.

We created all of the ORImpl classes as singletons, with the private constructor, static instance variable, getInstance() method, etc.

The ORImpl also has methods for retrieving/updating data in Oracle, so each method opens a connection, creates a PreparedStatement, executes the query, closes the connection, and so on.

Everything works fine and we are able to get data and update data. However, ever since we implemented the DAO's, we are getting serious OutOfMemory errors (like every day) in our application.

My question is this:

Suppose we have methods in the ORImpl that can return large amounts of data. The method creates a Collection, puts each record retrieved as an object (DTO) in the Collection, and returns the Collection to the calling class to do whatever it will. But since the ORImpl is created as a singleton and static, will the Collection that was created ever get garbage collected? The same method in the ORImpl could get called numerous times, returning different data each time, and creating a new Collection each time. The Collection itself is not created as static, but since the class that creates the Collection is static (a singleton), and never gets garbage collected, won't there always be a reference (the singleton) to each Collection that gets created, thereby causing it to never be garbage collected?

From what I've read about garbage collection, as long as there is a reference to an object, that object is reachable, and therefore unable to be garbage collected.

We also implemented EJB's at the same time as the DAO's, but we're only using stateless session beans (no entity beans), so the memory hit on those should be minimal.

Let me know what you think.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That your DAO is a singleton makes no difference with regard to the returned Collections. The only thing that can keep one of the Collections from being garbage collected is if a reachable object holds a referene to it. As long as the DAO doesn't store a reference to the Collection before returning it, the local variable reference to it will disappear once the method returns.

One thing that would help would be to use a profiling tool. They will tell you more than just performance bottlenecks. They'll give you how many of each type of object are being created and destroyed.

Are you pooling any resources (like DB connections)? If so, make sure you're returning them to the pool in every case. I doubt it's DB connections because you should run out of them, and even if your pool is set up as unlimited, I'd expect your database to complain sooner or later.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
a) Why are you using the Singleton antipattern? It is a nasty, horrible design flaw.
b) Suppose you go along with erroneous convention and disagree that Singleton is an antipattern (I can only assume that this happens because GoF has created some kind of doctrine, rather than a precedent from which to expand on their ideas), your static reference exists for the instance of the class (java.lang.Class); your class exists for the instance of the class loader that loaded it - your class becomes eligible for garbage collection when that class loader is garbage collected.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tony Morris:
a) Why are you using the Singleton antipattern? It is a nasty, horrible design flaw.
I disagree that Singleton is an anti-pattern. Surely it can be abused and used in the wrong place, but it's quite useful. Sometimes you really only need one instance of a class, especially when it's thread-safe and expensive to instantiate.
your static reference exists for the instance of the class (java.lang.Class); your class exists for the instance of the class loader that loaded it - your class becomes eligible for garbage collection when that class loader is garbage collected.
JDK 1.2 fixed the overly-aggressive class-unloading bug from JDK 1.1. Is this still an issue today?

In the application on which I'm currently working, we use Spring to wire up a bunch of singletons (DAOs and other business objects that provide services). The root is a Service object that is made available through a static inst() method, and it references all related objects to get its job done. Since the entire application is loaded by a single class loader, I don't see this as being a problem.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!