I believe most real-world ConnectionPool implementations get away with
their singleton-ness and supposedly garbage-collectable-ness by having a
background thread that keeps track of the static reference. This
background thread is responsible for items like monitoring stats,
reducing the pool
Cammarano Richard wrote:
i am currently using a connection pool manager that is designed as a
singleton where I call ConnectionManager.getInstance() to return the
single pool instance. At first I was storing the connection manager in
the servlet context until my coworker pointed out that I
On Fri, 7 Apr 2000, Sam Heisz wrote:
sam What stops the instance from getting garbage collected? I read
that
sam starting version something-something-something, the garbage
collector
sam is more aggressive and will collect instances of objects that are
only
sam referred to by a member variable in
Sam Heisz wrote:
wes What it may have meant was if Object A is only referred to by
Object B
wes and Object B is only referred to by Object A, they can be garbage
wes collected -- I can see where simple implementations of a garbage
wes collector wouldn't be able to deal with the circular
On Mon, 10 Apr 2000, Sam Heisz wrote:
"JDK 1.1.x specification added the feature of class unloading...
where the only reference to the Singleton object is maintained within
the Singleton class itself, the garbage collector, in its enthusiasm to
dispose of any unused trash, may assume that
Wes Biggs wrote:
On Mon, 10 Apr 2000, Sam Heisz wrote:
"JDK 1.1.x specification added the feature of class unloading...
where the only reference to the Singleton object is maintained within
the Singleton class itself, the garbage collector, in its enthusiasm to
dispose of any unused
On Mon, 10 Apr 2000, Craig R. McClanahan wrote:
It's actually the other way around in at least some JVMs -- the garbage collector
detects no other object references to an instance of your Singleton class (probably
because there is no such instance, if you're using all static methods).
Hmm..
Hi,
In our ConnectionPool class, we have a static initializer block that
actually gets the connections to the database for the pool. This is called
the very fist time any database is accessed. I would believe the init()
method would be a better place to do this, but during testing, you often
"Steven W. Rock" wrote:
Hi All,
Thanks for your thoughtful and enlightening threads of discussion on the
Model 2 architecture. I have been building a web site using Servlets, beans,
java classes and JSP based on this model. The one question I have which
seems to be missing from these
i am currently using a connection pool manager that is designed as a
singleton where I call ConnectionManager.getInstance() to return the
single pool instance. At first I was storing the connection manager in
the servlet context until my coworker pointed out that I didn't need to
store it at all.
Cammarano Richard wrote:
i am currently using a connection pool manager that is designed as a
singleton where I call ConnectionManager.getInstance() to return the
single pool instance. At first I was storing the connection manager in
the servlet context until my coworker pointed out that I
Hi,
One option to consider is storing the connection pool as a servlet context
attribute. Go ahead and create it in the init() method of your
controller servlet,
then execute:
ConnectionPool pool = ...;
getServletContext().setAttribute("pool", pool);
Agreed if you need to do it this
On Fri, 7 Apr 2000, Sam Heisz wrote:
What stops the instance from getting garbage collected? I read that
starting version something-something-something, the garbage collector is
more aggressive and will collect instances of objects that are only
referred to by a member variable in the same
13 matches
Mail list logo
