You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Torsten Curdt <tc...@dff.st> on 2002/08/01 16:45:01 UTC
[RT] pooling vs. release
...I just came across an idea. I remembered the discussion about the removal
of the "lookup/release" pattern in favor of a simple "lookup".
Would it possible to utilize the "finalize" method for pooled components?
A pooled component will get looked up and then used. In order to return it
into the pool we currently call "release".
I am not quite sure if this works at all... but couldn't the component
actually release _itself_ within finalize?
There are several problems:
1) finalize will only be triggered by the gc. so the components will locked
much longer than doing a straight release. (does this kind of pooling still
make sense?)
2) this only works if setting a self reference from within the finalize method
prevents the gc from destroying the object
Just a thought... any comments?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Torsten Curdt <tc...@dff.st>.
On Thursday 01 August 2002 17:32, Peter Royal wrote:
> On Thursday 01 August 2002 11:23 am, Torsten Curdt wrote:
> > ...but I was more thinking non-limited pools that exists only to reduce
> > object creations. Wouldn't it make sense there?
>
> Berin's comments explain that one better than I...
>
> > Thinking about limited pools... would it be cool to have a fall-back
> > mechanism? Just a week ago it took me quite some time find out that a
> > component did not release a jdbc connection.
> >
> > With this fallback mechanism I could immediatly have found in the log
> > file something like "WARN: releasing unused component..." without testing
> > the pool against it's limit.
>
> this is a pilfered idea i read somewhere else.. maybe even on this list...
must have missed that one...
> when a Connection is gotten from the pool, create a new Exception but don't
> throw it. If a connection is gotten from the pool, used, and then not
> closed, throw that exception upon finalization (which you should be able to
> force by shutting the system down).
>
> .. thats the rough idea..
You mean modifing the e.g. the Connection implementation? This would work for
a connection since it has it's close() methode which could remove the
exception again.
The problem is that the Poolable needs to know about it's state (in
use/released) to throw an Exception on finalization.
Is there something that is definitly is called when a component is looked up
or released? One could mime it with compose/dispose I guess...
Maybe one should always implement Poolables like this?
public class myclass implements Poolable, Composable, Disposable {
private boolean released = true;
public void compose(..) {
released = false;
}
public void dispose(..) {
released = true;
}
protected void finalize() {
if (!released) throw new UnreleasedComponentException("..");
}
}
But this may be a misuse of the current lifecycle interfaces...
What do you guys think?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Torsten Curdt <tc...@dff.st>.
On Thursday 01 August 2002 18:38, Leo Sutic wrote:
> > From: Peter Royal [mailto:proyal@apache.org]
> >
> > when a Connection is gotten from the pool, create a new
> > Exception but don't
> > throw it. If a connection is gotten from the pool, used, and
> > then not closed,
> > throw that exception upon finalization (which you should be
> > able to force by
> > shutting the system down).
> >
> > .. thats the rough idea..
>
> That was pretty much exactly what I did in MicroContainer -
> if you tried to release a component twice, or forgot to
> release it, it would print out a stack trace via an Exception.
> Basically "You did not release the component you had obtained
> here: (stack trace)", or "You have already released the component
> here: (stack trace) that you obtained here: (stack trace)". A very
> useful thing (I think), so I can testify to the goodness of Peter's tip.
>
> Just one thing: Finalizers are not run on exit by default
> (although this does not make Peter's suggestion less useful):
Ah... thanks for the info! This seems to be a really usefull addition!
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Peter Royal <pr...@apache.org>.
On Thursday 01 August 2002 01:06 pm, Berin Loritsch wrote:
> I take that back. I checked the source code for Throwable, it
> does fill in the stack trace on creation.
>
> Exceptions cause a strain on the JVM in all respects. Both creation
> and throwing.
>
> Keep in mind that if you "precreate" your exception to throw later,
> you incurr the fillInStackTrace() call twice. You have to call it
> again later to make sure it makes sense.
The idea is to "precreate" the exception when the component is looked up,
because you have then captured the line of code that is doing the lookup w/o
the matching release.
To answer Corey, yes this should be a debugging-only option for when you think
you may have a leak in your pool. Maybe this should be the excalibur/caulk
project :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch
>
> The component has no clue when it was obtained. It shouldn't, and
such
> a hack would cause more issues than it would solve.
Agree - it should be done via proxies as you describe.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> > If the component has a short lifetime then perhaps you could use a
> > timer thread (debugging only obviously) that starts screaming if a
> > component is not recycled/released in less than x seconds.
>
> I would need to guess how long the component will be used...
> That's the worst hack I could think of ;-)
It is also inherently ambiguous (probably violates IOC too):
/**
* When it is the programmer's fault.
*/
class WriteFasterCodeException extends RuntimeException {...}
/**
* When HotSpot is to blame. (Will automatically email Sun's
* development team as well.) Note that it extends Error and
* thus should not be caught by the application.
*/
class GoFasterError extends VirtualMachineError {...}
Seriously, though, it could be useful when you have a scarce resource
and you think some part of the system is holding on to it a bit too
long.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Torsten Curdt <tc...@dff.st>.
> If the component has a short lifetime then perhaps you could use a timer
> thread (debugging only obviously) that starts screaming if a component
> is not recycled/released in less than x seconds.
I would need to guess how long the component will be used...
That's the worst hack I could think of ;-)
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Berin Loritsch <bl...@apache.org>.
> From: Corey Jewett [mailto:cj@syntheticplayground.com]
>
> If the component has a short lifetime then perhaps you could
> use a timer thread (debugging only obviously) that starts
> screaming if a component is not recycled/released in less
> than x seconds.
Make that a short "use time". The component can be reused or
shared. That means that its life is long, but its time of use
is short. It is important to draw the distinction--or you will
start making false assumptions that affect the quality of your
software.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Corey Jewett <cj...@syntheticplayground.com>.
If the component has a short lifetime then perhaps you could use a timer
thread (debugging only obviously) that starts screaming if a component
is not recycled/released in less than x seconds.
Corey
On Thu, 2002-08-01 at 17:11, Torsten Curdt wrote:
> On Thursday 01 August 2002 19:07, Berin Loritsch wrote:
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > BTW, fillInStackTrace() is a native method (AKA a JNI method).
> >
> > oh yeah, it is synchronized as well.
> >
> > Creating tons of exceptions in a multithreaded environment is
> > not advised.
>
> well, a boolean should do it (see example) and the Exception could be created
> in finalize. Is there any other way a component could be aware of if it is
> used or not?
> --
> Torsten
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> I think you are asking the wrong question. Should an entity that
> is managed and controlled by an external force have any say in how
> it is managed? The answer to that is no, it violates COP principles.
aggreed. it shouldn't be task of component to care about such...
but working with the ECM it's only simple work around I could think of...
> Is this something that can be automagically added to any component
> by a dynamic proxy without any maintenance necessary in the hundreds
> of components we already have to maintain? Yes.
>
> Therefore, something like this should be an added feature of the
> container--making security and tracking this type of issue easier
> to maintain.
definitly!
well, then you can see it as feature request of the container ;-)
> One thing that is already doable in Fortress is adding request/release
> Instruments, and we can see if certain components are not being used
> in a balanced manner.
hm... I am getting more and more excited to see Fortress in action...
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Peter Donald <pe...@apache.org>.
On Fri, 2 Aug 2002 03:16, Berin Loritsch wrote:
> I think you are asking the wrong question. Should an entity that
> is managed and controlled by an external force have any say in how
> it is managed? The answer to that is no, it violates COP principles.
>
> Is this something that can be automagically added to any component
> by a dynamic proxy without any maintenance necessary in the hundreds
> of components we already have to maintain? Yes.
agred. Thats what Phoenix does for services.
--
Cheers,
Peter Donald
----------------------------------------------------------------
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Berin Loritsch <bl...@apache.org>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> On Thursday 01 August 2002 19:07, Berin Loritsch wrote:
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > BTW, fillInStackTrace() is a native method (AKA a JNI method).
> >
> > oh yeah, it is synchronized as well.
> >
> > Creating tons of exceptions in a multithreaded environment is not
> > advised.
>
> well, a boolean should do it (see example) and the Exception
> could be created
> in finalize. Is there any other way a component could be
> aware of if it is
> used or not?
> --
> Torsten
I think you are asking the wrong question. Should an entity that
is managed and controlled by an external force have any say in how
it is managed? The answer to that is no, it violates COP principles.
Is this something that can be automagically added to any component
by a dynamic proxy without any maintenance necessary in the hundreds
of components we already have to maintain? Yes.
Therefore, something like this should be an added feature of the
container--making security and tracking this type of issue easier
to maintain.
One thing that is already doable in Fortress is adding request/release
Instruments, and we can see if certain components are not being used
in a balanced manner.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Torsten Curdt <tc...@dff.st>.
On Thursday 01 August 2002 19:18, Leo Sutic wrote:
> > From: Torsten Curdt [mailto:tcurdt@dff.st]
> >
> > On Thursday 01 August 2002 19:07, Berin Loritsch wrote:
> > > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > > >
> > > > BTW, fillInStackTrace() is a native method (AKA a JNI method).
> > >
> > > oh yeah, it is synchronized as well.
> > >
> > > Creating tons of exceptions in a multithreaded environment is not
> > > advised.
> >
> > well, a boolean should do it (see example) and the Exception
> > could be created
> > in finalize.
>
> Much more useful to spew out the stack as it were when the component
> was obtained.
sure... was just a simplified example :-)
> That and a boolean flag == good.
...as long as the container cannot tell - I'll go for it
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Torsten Curdt [mailto:tcurdt@dff.st]
> >
> > On Thursday 01 August 2002 19:07, Berin Loritsch wrote:
> > > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > > >
> > > > BTW, fillInStackTrace() is a native method (AKA a JNI method).
> > >
> > > oh yeah, it is synchronized as well.
> > >
> > > Creating tons of exceptions in a multithreaded environment is not
> > > advised.
> >
> > well, a boolean should do it (see example) and the Exception
> > could be created
> > in finalize.
>
> Much more useful to spew out the stack as it were when the
> component was obtained.
>
> That and a boolean flag == good.
The component has no clue when it was obtained. It shouldn't, and
such a hack would cause more issues than it would solve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> On Thursday 01 August 2002 19:07, Berin Loritsch wrote:
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > BTW, fillInStackTrace() is a native method (AKA a JNI method).
> >
> > oh yeah, it is synchronized as well.
> >
> > Creating tons of exceptions in a multithreaded environment is not
> > advised.
>
> well, a boolean should do it (see example) and the Exception
> could be created
> in finalize.
Much more useful to spew out the stack as it were when the component
was obtained.
That and a boolean flag == good.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Torsten Curdt <tc...@dff.st>.
On Thursday 01 August 2002 19:07, Berin Loritsch wrote:
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > BTW, fillInStackTrace() is a native method (AKA a JNI method).
>
> oh yeah, it is synchronized as well.
>
> Creating tons of exceptions in a multithreaded environment is
> not advised.
well, a boolean should do it (see example) and the Exception could be created
in finalize. Is there any other way a component could be aware of if it is
used or not?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Berin Loritsch <bl...@apache.org>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> BTW, fillInStackTrace() is a native method (AKA a JNI method).
oh yeah, it is synchronized as well.
Creating tons of exceptions in a multithreaded environment is
not advised.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Berin Loritsch <bl...@apache.org>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > From: Corey Jewett [mailto:cj@syntheticplayground.com]
> >
> > A question on the strategy of creating exceptions to just
> > float around.
> >
> > It's my understanding that throwing exceptions causes a lot
> > of work in the JVM. What I'm unclear on is if this work is
> > from the throw, or from the Exception instantiation. If it's
> > from the instantiation then it would probably be a good idea
> > to bury this strategy under a debugging flag. Can anybody
> > clear this up for me?
>
> Creating is just creating.
I take that back. I checked the source code for Throwable, it
does fill in the stack trace on creation.
Exceptions cause a strain on the JVM in all respects. Both creation
and throwing.
Keep in mind that if you "precreate" your exception to throw later,
you incurr the fillInStackTrace() call twice. You have to call it
again later to make sure it makes sense.
BTW, fillInStackTrace() is a native method (AKA a JNI method).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Berin Loritsch <bl...@apache.org>.
> From: Corey Jewett [mailto:cj@syntheticplayground.com]
>
> A question on the strategy of creating exceptions to just
> float around.
>
> It's my understanding that throwing exceptions causes a lot
> of work in the JVM. What I'm unclear on is if this work is
> from the throw, or from the Exception instantiation. If it's
> from the instantiation then it would probably be a good idea
> to bury this strategy under a debugging flag. Can anybody
> clear this up for me?
Creating is just creating.
The issue is in the throwing. The exception needs to fill in
the stack trace, and go back through the stack trace in reverse
order until it is finally handled.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Corey Jewett <cj...@syntheticplayground.com>.
A question on the strategy of creating exceptions to just float around.
It's my understanding that throwing exceptions causes a lot of work in
the JVM. What I'm unclear on is if this work is from the throw, or from
the Exception instantiation. If it's from the instantiation then it
would probably be a good idea to bury this strategy under a debugging
flag. Can anybody clear this up for me?
Corey
On Thu, 2002-08-01 at 16:38, Leo Sutic wrote:
>
>
> > From: Peter Royal [mailto:proyal@apache.org]
> >
> > when a Connection is gotten from the pool, create a new
> > Exception but don't
> > throw it. If a connection is gotten from the pool, used, and
> > then not closed,
> > throw that exception upon finalization (which you should be
> > able to force by
> > shutting the system down).
> >
> > .. thats the rough idea..
>
> That was pretty much exactly what I did in MicroContainer -
> if you tried to release a component twice, or forgot to
> release it, it would print out a stack trace via an Exception.
> Basically "You did not release the component you had obtained
> here: (stack trace)", or "You have already released the component
> here: (stack trace) that you obtained here: (stack trace)". A very
> useful thing (I think), so I can testify to the goodness of Peter's tip.
>
> Just one thing: Finalizers are not run on exit by default
> (although this does not make Peter's suggestion less useful):
>
> java.lang
> Class System
>
> runFinalizersOnExit
>
> public static void runFinalizersOnExit(boolean value)
>
> Deprecated. This method is inherently unsafe. It may result
> in finalizers being called on live objects while other
> threads are concurrently manipulating those objects, resulting
> in erratic behavior or deadlock.
>
> Enable or disable finalization on exit; doing so specifies
> that the finalizers of all objects that have finalizers that
> have not yet been automatically invoked are to be run before
> the Java runtime exits. By default, finalization on exit is
> disabled.
>
> If there is a security manager, its checkExit method is first
> called with 0 as its argument to ensure the exit is allowed.
> This could result in a SecurityException.
>
> /LS
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Royal [mailto:proyal@apache.org]
>
> when a Connection is gotten from the pool, create a new
> Exception but don't
> throw it. If a connection is gotten from the pool, used, and
> then not closed,
> throw that exception upon finalization (which you should be
> able to force by
> shutting the system down).
>
> .. thats the rough idea..
That was pretty much exactly what I did in MicroContainer -
if you tried to release a component twice, or forgot to
release it, it would print out a stack trace via an Exception.
Basically "You did not release the component you had obtained
here: (stack trace)", or "You have already released the component
here: (stack trace) that you obtained here: (stack trace)". A very
useful thing (I think), so I can testify to the goodness of Peter's tip.
Just one thing: Finalizers are not run on exit by default
(although this does not make Peter's suggestion less useful):
java.lang
Class System
runFinalizersOnExit
public static void runFinalizersOnExit(boolean value)
Deprecated. This method is inherently unsafe. It may result
in finalizers being called on live objects while other
threads are concurrently manipulating those objects, resulting
in erratic behavior or deadlock.
Enable or disable finalization on exit; doing so specifies
that the finalizers of all objects that have finalizers that
have not yet been automatically invoked are to be run before
the Java runtime exits. By default, finalization on exit is
disabled.
If there is a security manager, its checkExit method is first
called with 0 as its argument to ensure the exit is allowed.
This could result in a SecurityException.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Peter Royal <pr...@apache.org>.
On Thursday 01 August 2002 11:23 am, Torsten Curdt wrote:
> ...but I was more thinking non-limited pools that exists only to reduce
> object creations. Wouldn't it make sense there?
Berin's comments explain that one better than I...
> Thinking about limited pools... would it be cool to have a fall-back
> mechanism? Just a week ago it took me quite some time find out that a
> component did not release a jdbc connection.
>
> With this fallback mechanism I could immediatly have found in the log file
> something like "WARN: releasing unused component..." without testing the
> pool against it's limit.
this is a pilfered idea i read somewhere else.. maybe even on this list...
when a Connection is gotten from the pool, create a new Exception but don't
throw it. If a connection is gotten from the pool, used, and then not closed,
throw that exception upon finalization (which you should be able to force by
shutting the system down).
.. thats the rough idea..
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Berin Loritsch <bl...@apache.org>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> On Thursday 01 August 2002 16:47, Peter Royal wrote:
> >
> > If we had deterministic gc, I think it might have a better
> chance of
> > being viable.
>
> aggreed!
>
> ...but I was more thinking non-limited pools that exists only
> to reduce object
> creations. Wouldn't it make sense there?
>
> Thinking about limited pools... would it be cool to have a fall-back
> mechanism? Just a week ago it took me quite some time find out that a
> component did not release a jdbc connection.
>
> With this fallback mechanism I could immediatly have found in
> the log file
> something like "WARN: releasing unused component..." without
> testing the pool
> against it's limit.
Remember, we need weak references in the pool to make that work. None
of our pool implementations use weak references.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Torsten Curdt <tc...@dff.st>.
On Thursday 01 August 2002 16:47, Peter Royal wrote:
> On Thursday 01 August 2002 10:45 am, Torsten Curdt wrote:
> > There are several problems:
> >
> > 1) finalize will only be triggered by the gc. so the components will
> > locked much longer than doing a straight release. (does this kind of
> > pooling still make sense?)
>
> I think you found the problem right there. If you are pooling a limited
> resource, say JDBC connections, you don't want to have to wait for the gc
> to kick in before you can get that connection back from the pool.
>
> If we had deterministic gc, I think it might have a better chance of being
> viable.
aggreed!
...but I was more thinking non-limited pools that exists only to reduce object
creations. Wouldn't it make sense there?
Thinking about limited pools... would it be cool to have a fall-back
mechanism? Just a week ago it took me quite some time find out that a
component did not release a jdbc connection.
With this fallback mechanism I could immediatly have found in the log file
something like "WARN: releasing unused component..." without testing the pool
against it's limit.
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> Also the pool would have to use weak references--or it will never
> get GC'd (a strong reference will exist in the pool--so the GC will
> never collect the pooled object).
oh... forgot about that one... true
> I think that it is also inherently flawed because once the finalize()
> method is called, the object is slated for removal--so there is no
> guarantee it will be there to reinsert into a pool. Also, a poorly
> implemented JVM might throw a memory protection exception trying to
> access an object that no longer exists in memory...
that's exactly what I fear, too :-(
But having such a fall-back mechanism would IMHO a very cool thing...
...anyway just a RT that came to my mind ;-)
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Peter Royal [mailto:proyal@apache.org]
> Sent: Thursday, August 01, 2002 10:47 AM
> To: Avalon Developers List
> Subject: Re: [RT] pooling vs. release
>
>
> On Thursday 01 August 2002 10:45 am, Torsten Curdt wrote:
> > There are several problems:
> >
> > 1) finalize will only be triggered by the gc. so the
> components will
> > locked much longer than doing a straight release. (does
> this kind of
> > pooling still make sense?)
>
> I think you found the problem right there. If you are pooling
> a limited
> resource, say JDBC connections, you don't want to have to
> wait for the gc to
> kick in before you can get that connection back from the pool.
>
> If we had deterministic gc, I think it might have a better
> chance of being
Also the pool would have to use weak references--or it will never
get GC'd (a strong reference will exist in the pool--so the GC will
never collect the pooled object).
I think that it is also inherently flawed because once the finalize()
method is called, the object is slated for removal--so there is no
guarantee it will be there to reinsert into a pool. Also, a poorly
implemented JVM might throw a memory protection exception trying to
access an object that no longer exists in memory...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Peter Royal <pr...@apache.org>.
On Thursday 01 August 2002 10:45 am, Torsten Curdt wrote:
> There are several problems:
>
> 1) finalize will only be triggered by the gc. so the components will locked
> much longer than doing a straight release. (does this kind of pooling still
> make sense?)
I think you found the problem right there. If you are pooling a limited
resource, say JDBC connections, you don't want to have to wait for the gc to
kick in before you can get that connection back from the pool.
If we had deterministic gc, I think it might have a better chance of being
viable.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Peter Donald <pe...@apache.org>.
On Fri, 2 Aug 2002 00:54, Leo Sutic wrote:
> > From: Torsten Curdt [mailto:tcurdt@dff.st]
> >
> > ...I just came across an idea. I remembered the discussion
> > about the removal
> > of the "lookup/release" pattern in favor of a simple "lookup".
> >
> > Would it possible to utilize the "finalize" method for pooled
> > components?
>
> I think we killed that suggestion. The motivation was that GC
> was too unpredictable, too slow, and the tuning had too coarse
> granularity.
And plain wont work unless we use wrappers for all our resources. The reason
being that any one object will only have finalize() called twice through its
entire life. So if the first finalize you push resource back into pool, its
death put off. If it happens a second time, finalize is not guarenteed to be
called again. At least that was my impression from a read ages ago though it
does sound very wrong.
--
Cheers,
Peter Donald
-----------------------------------------------------
When a stupid man is doing something he's ashamed of,
he always declares that it is his duty.
George Bernard Shaw
-----------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] pooling vs. release
Posted by Torsten Curdt <tc...@dff.st>.
On Thursday 01 August 2002 16:54, Leo Sutic wrote:
> > From: Torsten Curdt [mailto:tcurdt@dff.st]
> >
> > ...I just came across an idea. I remembered the discussion
> > about the removal
> > of the "lookup/release" pattern in favor of a simple "lookup".
> >
> > Would it possible to utilize the "finalize" method for pooled
> > components?
>
> I think we killed that suggestion. The motivation was that GC
> was too unpredictable, too slow, and the tuning had too coarse
> granularity.
yepp, aggree...
...but it would be a great fall-back mechanism - if it works at all.
Any idea if this will work at all?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] pooling vs. release
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> ...I just came across an idea. I remembered the discussion
> about the removal
> of the "lookup/release" pattern in favor of a simple "lookup".
>
> Would it possible to utilize the "finalize" method for pooled
> components?
I think we killed that suggestion. The motivation was that GC
was too unpredictable, too slow, and the tuning had too coarse
granularity.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>