proxool-developer — Developer's discussion list

[Proxool-developer] Analyzing SQL Queries

[Kiran T <mah...@ho...>]

Hello all,

In order to improve the efficiency of the website, I need to analyze all the 
SQL Queries and find the top 10 slowest( in terms of time it takes to 
complete execution)SQL queries. Is there a way to acheive this using Proxool 
?

I remeber this being discussed few months ago.

One solution would be split the existing OnExecute() method into 
OnExecuteStart() and OnExecuteEnd(). If changing an existing public method 
in the Proxool API is a concern, can a new method be added and let the 
existing OnExecute() do the function of either start or end event?( I am 
assuming OnExecute() currently gets executed at the beginning of the query 
execution.)

If this is something that can be rolled out to 1.0, is there a temporary 
solution to tackle this issue?

Thanks all in advance.

Kiran T

_________________________________________________________________
Express yourself with the new version of MSN Messenger! Download today - 
it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: [Proxool-developer] Connection Equality

[Bertrand R. <ber...@mo...>]

I agree with Christian, it is probably better to use the identity of the
underlying connection.
Moreover, AFAIK the JDBC specs don't say anything special about =
"connection
equality" - does it ?

And even if it does, someone using a connection pool would be crazy to =
base
his code on such equality... This would not be portable at all and would
strongly depend on the pool implementation.

-bertrand



----- Original Message -----
From: Craig Servin <cs...@cr...>
Date: Tue, 18 May 2004 22:50:06 -0500
To: pro...@li...
Subject: Re: [Proxool-developer] Connection Equality

> On Tuesday 18 May 2004 15:56, Bill Horsman wrote:
> > However, I wonder whether it will cause problems with some systems.=20
> > Christian, some of your/my code relies on being able to identify the =

> > same connection being used in a Map doesn't it? Any thoughts?
>=20
> It is a little bit strange to have equals() guarantee that it is the=20
> same
> connection.  I usually count on equals() to tell me something about
logical=20
> equality and =3D=3D to see if something is really the same object.

Your points are valid, but in pratice this will create problems for =
external
code that wants to reuse resources tied to a connection. For example:

We use a lot of clobs. Instead of creating a new clob each time we call =
our
procedures (up to 40 times a second) we tie a clob to a connection and =
reuse
the same clob each time. This is done by simply using the connection as =
the
key in a thread safe hash map.

So, for this reason I suggest that the wrapper uses the identity of the
underlying connection.

CHR

CHR
--=20
___________________________________________________________
Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now =
for
SourceForge Broadband and get the fastest 6.0/768 connection for only
$19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=3D2562&alloc_id=3D6184&op=3Dclick
_______________________________________________
Proxool-developer mailing list Pro...@li...
https://lists.sourceforge.net/lists/listinfo/proxool-developer

Re: [Proxool-developer] Connection Equality

[Christian N. <chr...@em...>]

----- Original Message -----
From: Craig Servin <cs...@cr...>
Date: Tue, 18 May 2004 22:50:06 -0500
To: pro...@li...
Subject: Re: [Proxool-developer] Connection Equality

> On Tuesday 18 May 2004 15:56, Bill Horsman wrote:
> > However, I wonder whether it will cause problems with some systems.
> > Christian, some of your/my code relies on being able to identify the
> > same connection being used in a Map doesn't it? Any thoughts?
> 
> It is a little bit strange to have equals() guarantee that it is the same 
> connection.  I usually count on equals() to tell me something about logical 
> equality and == to see if something is really the same object.

Your points are valid, but in pratice this will create problems for external code that wants to reuse resources tied to a connection. For example:

We use a lot of clobs. Instead of creating a new clob each time we call our procedures (up to 40 times a second) we tie a clob to a connection and reuse the same clob each time. This is done by simply using the connection as the key in a thread safe hash map.

So, for this reason I suggest that the wrapper uses the identity of the underlying connection.

CHR

CHR
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: [Proxool-developer] Connection Equality

[Craig S. <cs...@cr...>]

On Tuesday 18 May 2004 15:56, Bill Horsman wrote:
> However, I wonder whether it will cause problems with some systems.
> Christian, some of your/my code relies on being able to identify the
> same connection being used in a Map doesn't it? Any thoughts?

It is a little bit strange to have equals() guarantee that it is the same 
connection.  I usually count on equals() to tell me something about logical 
equality and == to see if something is really the same object.

for example:
      Date d1 = new Date();
      Date d2 = (Date) d1.clone();

      if ( d1.equals( d2 ) ) {

         // This is true
      }

      if ( d1 == d2  ) {

         // This is not
      }


This make it seem as though two connections should be equal if they come from 
the same pool and have the same state.  Since if they came from the same pool 
they would have all of the same logical properties.

Just my $.02,

Craig
-- 
In theory, practice and theory are the same, but in practice they are 
different
GPG Public Key https://www.cromagnon.com/ssl/craigkey.gpg

[Proxool-developer] Connection Equality

[Bill H. <bi...@lo...>]

Hi all,

I'm coding the disposable wrappers just now. And I just wanted to run
some behaviour past everyone.

Connection c1 = DriverManager.getConnection(url);
c1.close();

Connection c2 = DriverManager.getConnection(url);
c2.close();

// This test will ALWAYS be false, even if the actual
// underlying connection is the same
if (c1.equals(c2)) {
  // Never true!
}

Instinctively, this behaviour most closely matches the behaviour you'd
experience if you didn't have a pool at all.

However, I wonder whether it will cause problems with some systems.
Christian, some of your/my code relies on being able to identify the
same connection being used in a Map doesn't it? Any thoughts?

Note: I can code it either way. I'm just trying to work out which is the
sanest. The current (0.8.3) behaviour (because there are no disposable
wrappers) is:

if (c1.equals(c2)) {
  // True if, by coincidence, you get the same underlying 
  // connection back
}

- Bill

RE: [Proxool-developer] Re: Proxool behavior when max connection reached

[Bertrand R. <ber...@mo...>]

Thanks for your information Craig.

Work has already started on this feature together with some other
refactoring.
I don't know yet when it will be released but part of it may be =
available
soon in CVS. Keep listening on proxool-dev mailing list - I'll post a
message when it will start becoming available.

-bertrand


-----Original Message-----
From: pro...@li...
[mailto:pro...@li...] On Behalf Of =
Craig
Servin
Sent: samedi 15 mai 2004 21:45
To: pro...@li...
Subject: [Proxool-developer] Re: Proxool behavior when max connection
reached


Has any work been done on this.  I need a similar behavior and might try =
to=20
implement it, but I do not want to duplicate effort.

It seems that you would not need to more settings you would just need an =

allowed to wait count which if it was not 0 would make your normal limit
your=20
soft limit and then add to it for the hard limit.

It looks like there are only 2 spots in the code that would need to be=20
changed, but since the current code tries very hard not to synchronize I =
am=20
not sure of the best way to do this.  It would seem that if you would =
allow=20
for threads to wait you would want to synchronize at that point and then =

notify the threads as a connection is returned.  You could  simply check =
for

that feature being tunred on and only synchronize then, but you would =
have
to=20
make sure that if you hot change the settings to disable the waiting =
that
you=20
notify the waiting threads.



Craig

--=20
In theory, practice and theory are the same, but in practice they are=20
different
GPG Public Key https://www.cromagnon.com/ssl/craigkey.gpg


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now =
for
SourceForge Broadband and get the fastest 6.0/768 connection for only
$19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=3D2562&alloc_id=3D6184&op=3Dclick
_______________________________________________
Proxool-developer mailing list Pro...@li...
https://lists.sourceforge.net/lists/listinfo/proxool-developer

[Proxool-developer] Re: Proxool behavior when max connection reached

[Craig S. <cs...@cr...>]

Has any work been done on this.  I need a similar behavior and might try to 
implement it, but I do not want to duplicate effort.

It seems that you would not need to more settings you would just need an 
allowed to wait count which if it was not 0 would make your normal limit your 
soft limit and then add to it for the hard limit.

It looks like there are only 2 spots in the code that would need to be 
changed, but since the current code tries very hard not to synchronize I am 
not sure of the best way to do this.  It would seem that if you would allow 
for threads to wait you would want to synchronize at that point and then 
notify the threads as a connection is returned.  You could  simply check for 
that feature being tunred on and only synchronize then, but you would have to 
make sure that if you hot change the settings to disable the waiting that you 
notify the waiting threads.



Craig

-- 
In theory, practice and theory are the same, but in practice they are 
different
GPG Public Key https://www.cromagnon.com/ssl/craigkey.gpg

RE: [Proxool-developer] Re: Proxool behavior when max connectionreached

[Bill H. <bi...@lo...>]

Hi Bertrand,

On Thu, 2004-05-13 at 19:01, Bertrand Renuart wrote:

> > Work hasn't started on this, so feel free to contribute. The things to
> keep in mind are:
> 
> No 100% correct :(

Well, in my book that's good news :) Are you in a stage to share code
with Craig? Would that help you out?

> Have already started some work on it... And I'm close to 75% done.
> Not included in CVS code base yet but will be committed once 0.9 is out (and
> once I got a bit more free time :(

"Once 0.9 is out".... "a bit more free time"... Hmm

- Bill

RE: [Proxool-developer] Re: Proxool behavior when max connectionreached

[Bertrand R. <ber...@mo...>]

>> Has any work been done on this.  I need a similar behavior and might=20
>> try to
>> implement it, but I do not want to duplicate effort.

> Work hasn't started on this, so feel free to contribute. The things to
keep in mind are:

No 100% correct :(
Have already started some work on it... And I'm close to 75% done.
Not included in CVS code base yet but will be committed once 0.9 is out =
(and
once I got a bit more free time :(

-bertrand

Re: [Proxool-developer] Re: Proxool behavior when max connectionreached

[Christian N. <chr...@em...>]

Craig; You might want to have a look at the Commons Pool source.

GenericObjectPool (http://tinyurl.com/2maxb) supports 
WHEN_EXHAUSTED_FAIL
WHEN_EXHAUSTED_GROW
WHEN_EXHAUSTED_BLOCK (with a maxWait option)

You might also find something usefull in Doug Leas Channel (queue) stuff from util.concurrent (http://tinyurl.com/39o7y).

CHR

----- Original Message -----
From: Bill Horsman <bi...@lo...>
Date: Thu, 13 May 2004 14:12:35 +0100
To: Proxool Developer <pro...@li...>
Subject: Re: [Proxool-developer] Re: Proxool behavior when max connectionreached

> Craig,
> 
> On Thu, 2004-05-13 at 13:59, Craig Servin wrote:
> 
> > Has any work been done on this.  I need a similar behavior and might try to 
> > implement it, but I do not want to duplicate effort.
> 
> Work hasn't started on this, so feel free to contribute. The things to
> keep in mind are:
> 
> 1) If hard limit = soft limit then behaviour is as it is now. Without
> performance impact.
> 
> 2) If hard limit is reached then Proxool must refuse connections (throw
> SQLExceptions) as quickly as possible without too much processing. This
> ensures the server survives as long as possible under extremely heavy
> load.
> 
> 3) We don't want to be creating too many threads to support this
> behaviour. Ideally, none at all. But if we do create any it should be a
> fixed amount not additional ones for each connection.
> 
> If you need any help, feel free to post here.
> 
> - Bill
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: [Proxool-developer] Re: Proxool behavior when max connection reached

[Bill H. <bi...@lo...>]

Craig,

On Thu, 2004-05-13 at 13:59, Craig Servin wrote:

> Has any work been done on this.  I need a similar behavior and might try to 
> implement it, but I do not want to duplicate effort.

Work hasn't started on this, so feel free to contribute. The things to
keep in mind are:

1) If hard limit = soft limit then behaviour is as it is now. Without
performance impact.

2) If hard limit is reached then Proxool must refuse connections (throw
SQLExceptions) as quickly as possible without too much processing. This
ensures the server survives as long as possible under extremely heavy
load.

3) We don't want to be creating too many threads to support this
behaviour. Ideally, none at all. But if we do create any it should be a
fixed amount not additional ones for each connection.

If you need any help, feel free to post here.

- Bill

[Proxool-developer] Re: Proxool behavior when max connection reached

[Craig S. <cs...@cr...>]

Has any work been done on this.  I need a similar behavior and might try to 
implement it, but I do not want to duplicate effort.

Craig

-- 
In theory, practice and theory are the same, but in practice they are 
different
GPG Public Key https://www.cromagnon.com/ssl/craigkey.gpg

Re: [Proxool-developer] Unable to set status of connection 1 from ACTIVEto AVAILABLE

[Bill H. <bi...@lo...>]

Leon,

On Wed, 2004-05-12 at 23:04, Leon Noordermeer wrote:

> I get a lot of “[WARN] bog - -Unable to set status of connection 1
> from ACTIVEto AVAILABLE. It remains AVAILABLE” warnings 

This sounds like you are doing something worrying with closing
connections and then keeping them to reuse another time without giving
them back to Proxool. Could that be true?

> en it takes a lot of time before my data get’s committed to the
> database.

I'm not sure why that is. But it might become apparent if we explore
what else is happening.

> In a single transaction a couple of tables needs to be updated (about
> 5 of them) so what we do is setting autocommit off and add a number of
> update / insert statements to a connections and commit them at the
> very end. If anything goes wrong, we do a rollback and everything is
> fine J. 

Sounds cool.

> These connections are stored in a HashTable associated by the thread
> (we only use 1 connection for each thread). But when I store a
> connection in a thread an decide to add some statements later, I get
> the waning mentioned in the subject. Why is this? 

Warning bells are going off in my head. Why do you need to store the
connection in a hashtable? Usually I would expect a transaction to be

start
  execute#1
  execute#2
  ....
commit

I think if you can explain why you needed a hashtable and threads then
it will all become clear.

> Is there any way I can resolve this? By changing my code or even
> Proxool? 

You're welcome to do either :)

> I have just multiple connections which all must be performed or none
> at al I thought putting them in a HashTable by thread would be a good
> idea, but is it?

Let's see a bit more of your code and find out. 

In general, my advice would be:

1) Get a connection

2) Do all the things you need to do with it one after the other without
going off and doing other things.

3) Give it back to Proxoool (close it).

4) Don't use it again.

With reference to that last point, the elusive 0.9.0 will introduce
disposable connection wrappers that prohibit you being able to do
anything to a connection after it is closed. I can't wait...

- Bill

[Proxool-developer] Unable to set status of connection 1 from ACTIVEto AVAILABLE

[Leon N. <l.n...@wa...>]

Hi,
 
From a colleague I heard that proxool is a very good pooling mechanism
for JDBC connections. The beautiful thing is, he is right! :-) 
But, I have some problems implementing proxool in our current web
application. I get a lot of "[WARN] bog - -Unable to set status of
connection 1 from ACTIVEto AVAILABLE. It remains AVAILABLE" warnings en
it takes a lot of time before my data get's committed to the database.
 
Let me explain how it works on our side.
 
In a single transaction a couple of tables needs to be updated (about 5
of them) so what we do is setting autocommit off and add a number of
update / insert statements to a connections and commit them at the very
end. If anything goes wrong, we do a rollback and everything is fine
:-). 
These connections are stored in a HashTable associated by the thread (we
only use 1 connection for each thread). But when I store a connection in
a thread an decide to add some statements later, I get the waning
mentioned in the subject. Why is this? 
 
In all, I do not care about the warning. But it's makes the application
sluggish as a snail. (like it is waiting for timeouts).
 
Is there any way I can resolve this? By changing my code or even
Proxool? I have just multiple connections which all must be performed or
none at al I thought putting them in a HashTable by thread would be a
good idea, but is it?
 
With kind regards,
 
 
Leon
 

Re: [Proxool-developer] docs errors for AdminServlet

[Bill H. <bi...@lo...>]

On Sun, 2004-05-09 at 05:48, Michael Greer wrote:

> In the website, two errors for setting up Admin Servlet

Thanks Michael. I'll correct that for the 0.9 release. Or maybe sooner.

- Bill

[Proxool-developer] docs errors for AdminServlet

[Michael G. <mic...@ea...>]

In the website, two errors for setting up Admin Servlet

The docs say:
<servlet>
=A0=A0<servlet-name>proxool</servlet-name>
=A0=A0<servlet-class>org.logicalcobwebs.proxool.admin.AdminServlet</=20
servlet-class>
</servlet>

<servlet-mapping>
=A0=A0<servlet-name>Admin</servlet-name>
=A0=A0<url-pattern>/admin</url-pattern>
</servlet-mapping>

But it should be
<servlet>
=A0=A0<servlet-name>proxool</servlet-name>
=A0=A0<servlet-class> =20
org.logicalcobwebs.proxool.admin.servlet.AdminServlet</servlet-class>
</servlet>

<servlet-mapping>
=A0=A0<servlet-name>proxool</servlet-name>
=A0=A0<url-pattern>/admin</url-pattern>
</servlet-mapping>

cheers,
Michael Greer

RE: [Proxool-developer] Re: [Proxool-user] warning messages

[Bill H. <bi...@lo...>]

Michael,

On Thu, 2004-04-22 at 20:40, Michael Hoefer wrote:

> Locally I fixed it in perhaps a better way by checking if the hook is
> alive:
> 
> 	if (shutdownHook != null && !shutdownHook.isAlive() ) {
>         ShutdownHook.remove(shutdownHook);
>       }

And there we come across another fix that has been made since 0.8.3.
That ShutdownHook code is JDK 1.3 and isn't supported by JDK 1.2. That
was an oversight. CVS does the same using reflection to register a
shutdown hook only if the JDK supports it.

On Thu, 2004-04-22 at 20:43, Michael Hoefer wrote: 

 .The best solution is just to refactor the meat of the shutdown method
> into another method that is then invoked from the shutdownhook.
> Something like removeConnections(String finalizer, int delay)....

I agree. I'll look into it. I need to check whether that means we can
lose the test for an IllegalStateException. 

- Bill

RE: [Proxool-developer] Re: [Proxool-user] warning messages

[Michael H. <mh...@ni...>]

 ...but that on second thought is not the best as it is not
synchronized...

The best solution is just to refactor the meat of the shutdown method
into another method that is then invoked from the shutdownhook.
Something like removeConnections(String finalizer, int delay)....

-----Original Message-----
From: pro...@li...
[mailto:pro...@li...] On Behalf Of
Michael Hoefer
Sent: Thursday, April 22, 2004 12:40 PM
To: Proxool Developer List
Subject: RE: [Proxool-developer] Re: [Proxool-user] warning messages


Yep, I meant 'not'.

Locally I fixed it in perhaps a better way by checking if the hook is
alive:

	if (shutdownHook !=3D null && !shutdownHook.isAlive() ) {
        ShutdownHook.remove(shutdownHook);
      }

If it is alive, it means we are shutting down.  Solved the problem as
far as I can tell.  Code change is in ProxoolFacade.shutdown(...):

    /**
     * Removes all connection pools. Kills all the connections. Resets
everything.
     * @param finalizer used to identify who is causing the pools to be
removed (helps logging)
     * @param delay the time to wait for connections to become inactive
before killing it (milliseconds)
     */
    protected static void shutdown(String finalizer, int delay) {

        ConnectionPool[] cps =3D
ConnectionPoolManager.getInstance().getConnectionPools();
        for (int i =3D 0; i < cps.length; i++) {
            removeConnectionPool(finalizer, cps[i], delay);
        }

        // If a shutdown hook was registered then remove it...only if it
is not active
        try {
            if (shutdownHook !=3D null && !shutdownHook.isAlive() ) {
                ShutdownHook.remove(shutdownHook);
            }
        } catch (Throwable t) {
            if (LOG.isDebugEnabled()) {
                LOG.debug("Unanticipated error during removal of
ShutdownHook. Ignoring it.", t);
            }
        }

    }


-----Original Message-----
From: pro...@li...
[mailto:pro...@li...] On Behalf Of Bill
Horsman
Sent: Thursday, April 22, 2004 12:37 PM
To: Proxool Developer List
Subject: Re: [Proxool-developer] Re: [Proxool-user] warning messages

Michael,

On Thu, 2004-04-22 at 20:26, Michael Hoefer wrote:

> Now as far as I've read, you are now allowed to remove shutdown hooks

> after a shutdown has been initiated.

I think you meant "/not/ allowed"?

> ProxoolFacade should be refactored to not remove any shutdown hooks

> when called from the shutdown hook itself.  I'm surprised nobody else

> has seen this...am I missing something?

Nope. It's a known problem. The latest code in CVS copes with it, albeit
in a clumsy way. It still tries to remove the shutdownHook but it spots
an IllegalStateException and silently ignores it. Perhaps we could do
that in a smarter way.

- Bill



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For
a limited time only, get FREE Ground shipping on all orders of $35 or
more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=3D12297
_______________________________________________
Proxool-developer mailing list
Pro...@li...
https://lists.sourceforge.net/lists/listinfo/proxool-developer



CONFIDENTIALITY NOTICE: The information contained in this message and or
attachments is intended only for the person or entity to which it is
addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination, copying, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you received this e-mail or its attachments in error,
please contact the sender and delete the material from any system and
destroy any copies.


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For
a limited time only, get FREE Ground shipping on all orders of $35 or
more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
Proxool-developer mailing list
Pro...@li...
https://lists.sourceforge.net/lists/listinfo/proxool-developer



CONFIDENTIALITY NOTICE: The information contained in this message and or=
 attachments is intended only for the person or entity to which it is=
 addressed and may contain confidential and/or privileged material. Any=
 review, retransmission, dissemination, copying, or other use of this=
 information by persons or entities other than the intended recipient is=
 prohibited. If you received this e-mail or its attachments in error,=
 please contact the sender and delete the material from any system and=
 destroy any copies.

RE: [Proxool-developer] Re: [Proxool-user] warning messages

[Michael H. <mh...@ni...>]

Yep, I meant 'not'.

Locally I fixed it in perhaps a better way by checking if the hook is
alive:

	if (shutdownHook !=3D null && !shutdownHook.isAlive() ) {
        ShutdownHook.remove(shutdownHook);
      }

If it is alive, it means we are shutting down.  Solved the problem as
far as I can tell.  Code change is in ProxoolFacade.shutdown(...):

    /**
     * Removes all connection pools. Kills all the connections. Resets
everything.
     * @param finalizer used to identify who is causing the pools to be
removed (helps logging)
     * @param delay the time to wait for connections to become inactive
before killing it (milliseconds)
     */
    protected static void shutdown(String finalizer, int delay) {

        ConnectionPool[] cps =3D
ConnectionPoolManager.getInstance().getConnectionPools();
        for (int i =3D 0; i < cps.length; i++) {
            removeConnectionPool(finalizer, cps[i], delay);
        }

        // If a shutdown hook was registered then remove it...only if it
is not active
        try {
            if (shutdownHook !=3D null && !shutdownHook.isAlive() ) {
                ShutdownHook.remove(shutdownHook);
            }
        } catch (Throwable t) {
            if (LOG.isDebugEnabled()) {
                LOG.debug("Unanticipated error during removal of
ShutdownHook. Ignoring it.", t);
            }
        }

    }=0D

-----Original Message-----
From: pro...@li...
[mailto:pro...@li...] On Behalf Of Bill
Horsman
Sent: Thursday, April 22, 2004 12:37 PM
To: Proxool Developer List
Subject: Re: [Proxool-developer] Re: [Proxool-user] warning messages

Michael,

On Thu, 2004-04-22 at 20:26, Michael Hoefer wrote:

> Now as far as I've read, you are now allowed to remove shutdown hooks=0D
> after a shutdown has been initiated.

I think you meant "/not/ allowed"?

> ProxoolFacade should be refactored to not remove any shutdown hooks=0D
> when called from the shutdown hook itself.  I'm surprised nobody else=0D
> has seen this...am I missing something?

Nope. It's a known problem. The latest code in CVS copes with it, albeit
in a clumsy way. It still tries to remove the shutdownHook but it spots
an IllegalStateException and silently ignores it. Perhaps we could do
that in a smarter way.

- Bill



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For
a limited time only, get FREE Ground shipping on all orders of $35 or
more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=3D12297
_______________________________________________
Proxool-developer mailing list
Pro...@li...
https://lists.sourceforge.net/lists/listinfo/proxool-developer



CONFIDENTIALITY NOTICE: The information contained in this message and or=
 attachments is intended only for the person or entity to which it is=
 addressed and may contain confidential and/or privileged material. Any=
 review, retransmission, dissemination, copying, or other use of this=
 information by persons or entities other than the intended recipient is=
 prohibited. If you received this e-mail or its attachments in error,=
 please contact the sender and delete the material from any system and=
 destroy any copies.

Re: [Proxool-developer] Re: [Proxool-user] warning messages

[Bill H. <bi...@lo...>]

Michael,

On Thu, 2004-04-22 at 20:26, Michael Hoefer wrote:

> Now as far as I've read, you are now allowed to remove shutdown hooks
> after a shutdown has been initiated.  

I think you meant "/not/ allowed"?

> ProxoolFacade should be refactored to not remove any shutdown hooks
> when called from the shutdown hook itself.  I'm surprised nobody else
> has seen this...am I missing something?

Nope. It's a known problem. The latest code in CVS copes with it, albeit
in a clumsy way. It still tries to remove the shutdownHook but it spots
an IllegalStateException and silently ignores it. Perhaps we could do
that in a smarter way.

- Bill

[Proxool-developer] Re: [Proxool-user] warning messages

[Michael H. <mh...@ni...>]

Hi there...I'm getting the same errors, and they seem to be correct.
Using 0.8.3.  Now as far as I've read, you are now allowed to remove
shutdown hooks after a shutdown has been initiated.  Yet this is exactly
what proxool is trying to do.  Looks like a bug to me.  ProxoolFacade
should be refactored to not remove any shutdown hooks when called from
the shutdown hook itself.  I'm surprised nobody else has seen this...am
I missing something?
=0D
    /**
     * Remove all connection pools without delay
     * @see ProxoolFacade#removeAllConnectionPools
     */
    public void run() {
        LOG.debug("Running ShutdownHook");
        Thread.currentThread().setName("Shutdown Hook");
        ProxoolFacade.shutdown(0);
    }
=0D
WHICH CALLS...
=0D
/**
     * Removes all connection pools. Kills all the connections. Resets
everything.
     * @param finalizer used to identify who is causing the pools to be
removed (helps logging)
     * @param delay the time to wait for connections to become inactive
before killing it (milliseconds)
     */
    protected static void shutdown(String finalizer, int delay) {
=0D
        ConnectionPool[] cps =3D
ConnectionPoolManager.getInstance().getConnectionPools();
        for (int i =3D 0; i < cps.length; i++) {
            removeConnectionPool(finalizer, cps[i], delay);
        }
=0D
        // If a shutdown hook was registered then remove it
        try {
            if (shutdownHook !=3D null) {
                ShutdownHook.remove(shutdownHook);
            }
        } catch (Throwable t) {
            if (LOG.isDebugEnabled()) {
                LOG.debug("Unanticipated error during removal of
ShutdownHook. Ignoring it.", t);
            }
        }
    }
=0D
=0D
--=0D
Michael Hoefer
Architect
Software Engineering

Niku Corporation
305 Main Street
Redwood City, CA 94063

Tel: 	650.298.5916
Fax: 	650.298.5946
Web: 	www.niku.com
=0D


CONFIDENTIALITY NOTICE: The information contained in this message and or=
 attachments is intended only for the person or entity to which it is=
 addressed and may contain confidential and/or privileged material. Any=
 review, retransmission, dissemination, copying, or other use of this=
 information by persons or entities other than the intended recipient is=
 prohibited. If you received this e-mail or its attachments in error,=
 please contact the sender and delete the material from any system and=
 destroy any copies.

RE: [Proxool-developer] Stumbling Block for Proxying Concrete Classes

[Bill H. <bi...@lo...>]

Bertrand,

On Wed, 2004-04-07 at 23:18, Bertrand Renuart wrote:

> Don't you think all this is enough (without being too complicated) to make
> most people happy ?

Yep, I do. The point is that proxying the concrete class was going to be
a lot simpler than injectable interfaces :( That was the point in
pursuing it. I will progress injectable interfaces now though: I've
already done the configuration and most of the proxy code. It just
remains for me to do the cached map between interface methods and
concrete methods.

You're summary is correct.

- Bill

[Proxool-developer] Stumbling Block for Proxying Concrete Classes

[Bill H. <bi...@lo...>]

Hi all,

I've spent a few hours playing with Cglib and talking to the developers
trying to get concrete class proxying to work. And there is a
fundamental problem :(

Proxying for objects that declare all their important methods in an
interface is not a problem. It's when we try and expose some of methods
that are only declared in the concrete class that we get problems.

Cglib /will/ allow us to do it, but we have to extend the concrete
class. And to do that the concrete class must be non-final and have at
least one non-private constructor. And if there isn't a default
constructor then it starts to get a bit awkward because you end up
guessing the parameters. Nasty. 

This is what happens: we get a Connection object, say, from the driver
and want to proxy it and expose the concrete class. We ask Cglib to
build a new object based on a class that extends the concrete class. At
this point, it instantiates another instance. This is the big problem in
my mind. Now, we never actually use that instance - our proxy always
delegates to the instance we were handed by the driver. Nevertheless, we
have no idea what the consequences are of instantiating another
Connection object. Maybe it will try and connect to the database, or
make the driver think there are more open connections than there really
are.

To quote Chris Nokleberg from Cglib: "But unfortunately there is no way
to proxy an existing class without creating a new copy (you cannot
modify the bytecode of an existing class/object). Proxying by interface
works fine because you can always create a new class that implements the
interface. I wish I could help but it is a pretty fundamental JVM
limitation."

So we are left with injectable interfaces. This is possible, although we
need to do a bit of work. You can't make the concrete class implement
your new injectable interface: reflection just won't allow it. But we
will be able to match up the concrete methods with the injectable
interface methods using their signatures. This will allow us to create a
map of interface methods to concrete methods (that will be cached for
speed). I don't see any reason why this can't work.

It's a shame, because proxying the concrete class seemed like such a
neat solution. Injectable Interfaces are functional, but the client
needs to write and configure them. Anybody have an ideas?

- Bill

Re: [Proxool-developer] Driver specific interfaces

[<chr...@em...>]

Well argued Bertrand :)

And yes Bill, a fully blown AOP soution is a bit on the horizon.

I'm sold methinks.

Implement it and lets see how it works out.

CHR



Bill Horsman wrote:

>On Wed, 2004-03-24 at 22:11, Christian Nedregård wrote:
>
>  
>
>>I hate to be the devils advocate here... 
>>    
>>
>
>But a useful role :)
>
>  
>
>>but maybe we can find a more simple and generic way of doing this?
>>    
>>
>
>I'm with you so far...
>
>  
>
>>How about evaluating a full blown AOP approach instead? 
>>    
>>
>
>That seems like a big step. Would it be possible to have an AOP solution
>alongside the proxy one? I think it should be a configurable option (if
>that is possible)
>
>  
>
>>simply  intercept the  methods  we  need to handle specially. 
>>    
>>
>
>I like the "simply" ;-)
>
>  
>
>>This will prevent us from using the disposable wrapper though (i
>>think)...
>>    
>>
>
>I would hope not. Or at least, an AOP solution should be as robust as
>disposable wrappers.
>
>By all means, lets explore an AOP solution. But it has to be as well as
>these other solutions we are providing. If Proxool-AOP becomes a good
>solution then it might replace the current system but I don't see that
>happening anytime soon.
>
>- Bill
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
>_______________________________________________
>Proxool-developer mailing list
>Pro...@li...
>https://lists.sourceforge.net/lists/listinfo/proxool-developer
>
>  
>

Re: [Proxool-developer] Driver specific interfaces

[Bill H. <bi...@lo...>]

On Wed, 2004-03-24 at 22:11, Christian Nedreg=E5rd wrote:

> I hate to be the devils advocate here...=20

But a useful role :)

> but maybe we can find a more simple and generic way of doing this?

I'm with you so far...

> How about evaluating a full blown AOP approach instead?=20

That seems like a big step. Would it be possible to have an AOP solution
alongside the proxy one? I think it should be a configurable option (if
that is possible)

> simply  intercept the  methods  we  need to handle specially.=20

I like the "simply" ;-)

> This will prevent us from using the disposable wrapper though (i
> think)...

I would hope not. Or at least, an AOP solution should be as robust as
disposable wrappers.

By all means, lets explore an AOP solution. But it has to be as well as
these other solutions we are providing. If Proxool-AOP becomes a good
solution then it might replace the current system but I don't see that
happening anytime soon.

- Bill