Eric Fillman

Greenhorn
+ Follow
since Mar 18, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Eric Fillman

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.
16 years ago
We have a large amount of data that rarely changes that needs to be accessed through our web site. Currently, the data is queried via JDBC everytime someone wants to look at it, but some of the queries can take a long time. We are now in the process of coming up with a design to cache the data in memory and retrieve it from there, with a background process running to update the cache in the event that the database data does change.
Has anybody tried to implement the Lifetime-In-Cache with entity beans that WebSphere 5 provides?
If so, what were the results on performance, response times, etc.?
Would it be better/easier to simply cache the data in memory using POJO's or some other "tool" (OS Cache?)?
Any help would be appreciated.
Thanks.
Eric
17 years ago