proxool-developer Mailing List for Proxool: Proxy JDBC Connection Pool (Page 17)
UNMAINTAINED!
Brought to you by:
billhorsman
Menu
▾
▴
proxool-developer — Developer's discussion list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(54) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(15) |
Feb
(56) |
Mar
(9) |
Apr
(6) |
May
(12) |
Jun
(4) |
Jul
|
Aug
(9) |
Sep
(21) |
Oct
(10) |
Nov
(19) |
Dec
(29) |
| 2004 |
Jan
(11) |
Feb
(12) |
Mar
(53) |
Apr
(7) |
May
(15) |
Jun
(6) |
Jul
(6) |
Aug
|
Sep
(11) |
Oct
(7) |
Nov
(3) |
Dec
(3) |
| 2005 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(4) |
Aug
(2) |
Sep
(10) |
Oct
(4) |
Nov
|
Dec
(1) |
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2007 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(7) |
| 2008 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
(3) |
Sep
(5) |
Oct
|
Nov
(2) |
Dec
(2) |
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
(18) |
May
(4) |
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Martin C. <mus...@us...> - 2003-02-05 15:26:01
|
> We should definitely document that sort of behaviour. I just tried to > test that out but came across some class loading problems with the > commons-logging (I'm using Tomcat 4.1.18). Martin, have you got this > working? Does it behave as expected (on application reload)? I was able to deploy it in the commons directory, and I'm sure it its Tomcat 4.1.18. I will have to verify this on my other computer though. I might have had to transfer the commons-logging.jar too. I'll get back to you on this. Martin |
|
From: Bill H. <bi...@lo...> - 2003-02-05 15:12:46
|
On Wed, 2003-02-05 at 14:57, Christian Nedregaard wrote:
> Or maybe just use the ServletConfigurator servlet Bill is writing for 0.7.
And I've just committed it. This was Andrew Budarevsky's idea. To
configure Proxool and to get it to shutdown correctly you just need to
add something like this to your web.xml:
<servlet>
<servlet-name>ServletConfigurator</servlet-name>
<servlet-class>org.logicalcobwebs.proxool.configuration.ServletConfigurator</servlet-class>
<init-param>
<param-name>xmlFile</param-name>
<param-value>WEB-INF/proxool.xml</param-value>
</init-param>
</servlet>
If, for any reason, you don't want it to autoShutdown you can add:
<init-param>
<param-name>autoShutdown</param-name>
<param-value>false</param-value>
</init-param>
I'm going to be busy documenting the conclusions (?) from these
discussions now :( I'll post something on
http://proxool.sourceforge.net/dev (which is where I put draft
documentation prior to a release).
--
Bill Horsman
Proxool
http://proxool.sourceforge.net
ICQ: 119577180
|
|
From: Christian N. <chr...@em...> - 2003-02-05 14:57:39
|
> I know, I've stated my thoughts on this before, but again I'll restate > it: Proxool should not be installed at an individual web application > level, but at the common classloader level. On *general* terms I disagree. IMHO moving 3rd party libraries up to the container classloader level is almost alvays a bad idea. The two main problems are these: 1)Classloader/version conflicts. When you move a library up to the container classloader you expose the other apps in the container to danger if they include diffenrent versions of some of the same 3rd party libraries as the globally exposed library. This can result in ClassCastExeptions, problems with SEARIALID and unpredictable behaviour. I've experienced this many times with commonly used libraries such as Log4J and JAXP. As Bill said, he got this problem immediately with Proxool due to conflicts with Commons logging. This problem will increase with any additional 3rd party libraries we choose to depend on (if any...). Maybe we should just get the Commons logging code and refacor it as Proxool code (the Apache licence allows us to do so). This will solve the classloader issues and retain our dynamic logging support. 2) Making your app dependant on a non-standard container. To be portable web apps should only depend on a clean J2EE container (not a J2EE container + general libraries). This is again on general terms. If Proxool is used totally transparently as a JDBC driver this problem dissapears I guess. You certainly have some good arguments for making it global. Especially your point about sharing pools across applications. > You want one instance of proxool per VM to ensure the Singleton pattern > is enforced. Er.. This might be a bit picky, but technically this will not break the Singleton pattern as instances of Proxool spawned from differnent classloaders are not instances of the same class. > Additionally, of course, you break the transparency by forcing Servlet > developers to write proxool specific code within their Servlet > application. > And which Servlet would I write this "destroy" code if my > web application has multiple Servlets? Wichever you like. Or maybe just use the ServletConfigurator servlet Bill is writing for 0.7. > Proxool is most effective because > of its transparency, I say we should foster this transparency. Yes, this is a strong argument, but must be weighted aginst the problems mentioned above. It is also a strong argument for Proxool to implement DataSource since this is the standard way of appservers to serve connections shared by different apps. I used to be aginst us implementing DataSource, but now I have changed my mind. Thanks Martin :) This is an open ended discussion that have strong advocates for either apporach. For instance: Struts recommends deployment in each app, while Log4J recommends gobal deployment. I suggest we document both approaches with the pros and cons for each. CHR -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife |
|
From: Bill H. <bi...@lo...> - 2003-02-05 11:21:24
|
Hi Andrew, On Wed, 2003-02-05 at 09:36, Andrew Budarevsky wrote: > Please don't be confused with event term. Destroy method is actually > the event the servlet receives on container state change. I see. So you mean a servlet that would implement the destroy method and perhaps help to make configuration easier? I like that. We already (in 0.7) have a MonitorServlet; why not have another servlet for other tasks. Like: 1. Shutting down Proxool 2. Configuring Proxool from file -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Bill H. <bi...@lo...> - 2003-02-05 10:11:49
|
On Wed, 2003-02-05 at 02:12, Martin Crawford wrote: > And which Servlet would I write this "destroy" code if my > web application has multiple Servlets? Well... you could shutdown each pool individually. But I agree that that is a bit cumbersome. I only mention it as a possible solution. > Proxool is most effective because of its transparency, I say > we should foster this transparency. Absolutely. It might even make us unique? The question is, how to combine the ease of use of the XML configurators and potentially useful things like statistics whilst still retaining transparency? Is it one or the other? You either have a transparent pool with no advanced stuff, or you make a dependency on Proxool and get to use all the "bells and whistles". I mean, we should cater for both scenarios and leave it up to the user to choose. > My 0.5 cents (Canadian dollar isn't doing to well) You can spend you dollars here anytime, Martin. -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Bill H. <bi...@lo...> - 2003-02-05 10:11:48
|
On Wed, 2003-02-05 at 02:12, Martin Crawford wrote: > And which Servlet would I write this "destroy" code if my > web application has multiple Servlets? Well... you could shutdown each pool individually. But I agree that that is a bit cumbersome. I only mention it as a possible solution. > Proxool is most effective because of its transparency, I say > we should foster this transparency. Absolutely. It might even make us unique? The question is, how to combine the ease of use of the XML configurators and potentially useful things like statistics whilst still retaining transparency? Is it one or the other? You either have a transparent pool with no advanced stuff, or you make a dependency on Proxool and get to use all the "bells and whistles". I mean, we should cater for both scenarios and leave it up to the user to choose. > My 0.5 cents (Canadian dollar isn't doing to well) You can spend you dollars here anytime, Martin. -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Bill H. <bi...@lo...> - 2003-02-05 10:07:01
|
On Wed, 2003-02-05 at 02:12, Martin Crawford wrote: > You want one instance of proxool per VM to ensure the Singleton pattern > is enforced. By deploying the JAR with each individual application, you > end up creating multiple instances of the Proxool framework. Thus > breaking the Singleton pattern. > > Imagine a Servlet container connecting to the same database for several > different web applications. You would not benefit from the beauty of > managing your pools efficiently across all applications. We should definitely document that sort of behaviour. I just tried to test that out but came across some class loading problems with the commons-logging (I'm using Tomcat 4.1.18). Martin, have you got this working? Does it behave as expected (on application reload)? -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Andrew B. <ne...@my...> - 2003-02-05 10:02:06
|
Hi All! > Of course the customization requires from user to use pool facade > directly.=20 Not true. At least, if I understand you correctly. You can configure Proxool using a Properties object sent to the Driver. It is the clumsiest way of configuring it but it is there for precisely that reason. [The JAXPConfjigurator is the nicest way :)] -------------------8<-------------------------------- I had to say that I was not going to hightlight the only problems. I descri= bed how the design in my opninion should look like. I didn't mean that th= is feature is absent. I am aware of properties based way of pool configur= ation. I just selected of few leveles of responsibility. Please don't get= it serious. If you remebered I divided the pool behaviour on two parts: = default (transparent) and customized. The customization as a term require= s user participation in general. -------------------8<-------------------------------- > I would recom=D1=8Cend to make a wrapper around pool facade reinitializin= g > the pool on getting servlet events. But then what API does the wrapper adhere to? Is there a spec. for servlets doing this? --------------8<--------------------- Please don't be confused with event term. Destroy method is actually the ev= ent the servlet receives on container state change. --------------8<--------------------- > I am sorry for such a long essay I welcome it. Keep it up, Andrew. Out of our differences and misunderstandings will rise a better Proxool :) --------------8<--------------------- No doubts! :) --------------8<--------------------- Andrew. |
|
From: Andrew B. <ne...@my...> - 2003-02-05 10:02:06
|
Hi All! > Of course the customization requires from user to use pool facade > directly.=20 Not true. At least, if I understand you correctly. You can configure Proxool using a Properties object sent to the Driver. It is the clumsiest way of configuring it but it is there for precisely that reason. [The JAXPConfjigurator is the nicest way :)] -------------------8<-------------------------------- I had to say that I was not going to hightlight the only problems. I descri= bed how the design in my opninion should look like. I didn't mean that th= is feature is absent. I am aware of properties based way of pool configur= ation. I just selected of few leveles of responsibility. Please don't get= it serious. If you remebered I divided the pool behaviour on two parts: = default (transparent) and customized. The customization as a term require= s user participation in general. -------------------8<-------------------------------- > I would recom=D1=8Cend to make a wrapper around pool facade reinitializin= g > the pool on getting servlet events. But then what API does the wrapper adhere to? Is there a spec. for servlets doing this? --------------8<--------------------- Please don't be confused with event term. Destroy method is actually the ev= ent the servlet receives on container state change. --------------8<--------------------- > I am sorry for such a long essay I welcome it. Keep it up, Andrew. Out of our differences and misunderstandings will rise a better Proxool :) --------------8<--------------------- No doubts! :) --------------8<--------------------- Andrew. |
|
From: Andrew B. <ne...@my...> - 2003-02-05 10:02:05
|
Hi All! > Of course the customization requires from user to use pool facade > directly.=20 Not true. At least, if I understand you correctly. You can configure Proxool using a Properties object sent to the Driver. It is the clumsiest way of configuring it but it is there for precisely that reason. [The JAXPConfjigurator is the nicest way :)] -------------------8<-------------------------------- I had to say that I was not going to hightlight the only problems. I descri= bed how the design in my opninion should look like. I didn't mean that th= is feature is absent. I am aware of properties based way of pool configur= ation. I just selected of few leveles of responsibility. Please don't get= it serious. If you remebered I divided the pool behaviour on two parts: = default (transparent) and customized. The customization as a term require= s user participation in general. -------------------8<-------------------------------- > I would recom=D1=8Cend to make a wrapper around pool facade reinitializin= g > the pool on getting servlet events. But then what API does the wrapper adhere to? Is there a spec. for servlets doing this? --------------8<--------------------- Please don't be confused with event term. Destroy method is actually the ev= ent the servlet receives on container state change. --------------8<--------------------- > I am sorry for such a long essay I welcome it. Keep it up, Andrew. Out of our differences and misunderstandings will rise a better Proxool :) --------------8<--------------------- No doubts! :) --------------8<--------------------- Andrew. |
|
From: Martin C. <mus...@us...> - 2003-02-05 02:13:00
|
> The real problem is shutting down the pool on application reloads. Our > current implementation of this has been proved to be very unpredicable, so I > think we need to document *very clearly* that all applications that expect > to be reloaded must shutdown proxool in some kind of container spesific > manner. As you mention, Servlet.destroy() is a good place to do this in a > servlet container. Most other environments will hopefully also provide > something similar (like Disposable.dispose() in a Avalon container). I know, I've stated my thoughts on this before, but again I'll restate it: Proxool should not be installed at an individual web application level, but at the common classloader level. You want one instance of proxool per VM to ensure the Singleton pattern is enforced. By deploying the JAR with each individual application, you end up creating multiple instances of the Proxool framework. Thus breaking the Singleton pattern. Imagine a Servlet container connecting to the same database for several different web applications. You would not benefit from the beauty of managing your pools efficiently across all applications. Additionally, of course, you break the transparency by forcing Servlet developers to write proxool specific code within their Servlet application. And which Servlet would I write this "destroy" code if my web application has multiple Servlets? Proxool is most effective because of its transparency, I say we should foster this transparency. My 0.5 cents (Canadian dollar isn't doing to well) Martin |
|
From: Bill H. <bi...@lo...> - 2003-02-05 00:42:42
|
Hi Andrew, On Wed, 2003-02-05 at 00:15, Andrew Budarevsky wrote: > 1. Default pool behaviour > <snip> the ABL should not even suspect the existence of the pool. > That's why the pool's behaviour should be transparent as much as > possible. I totally agree. As far as we know, the only time that the ABL (if you like) needs to know about Proxool is when you are reloading apps into a ServletContainer. In this instance, the Servlet's destroy() method is called but the ShutdownHook isn't. But all the pools are gracefully shutdown when the servlet container is shut down (eventually). We did have a solution to this that used System properties but the use of System properties is precluded by the J2EE spec. We have decided to be compliant even though it makes this task difficult. > 2. Work-arounds for JVMs that are not fully compatible <snip> It is > bad idea to hardcode such work-arounds. I don't think we are. > method like shutdownPool() having empty signature. The name of such > method must correspond to action semantics. Yes, I agree. removeAllConnectionPools is a bad name. I will deprecate it in favour of somethig like shutdown(). > ... currently the pool provides statistics with INFO log message type. > In some cases it might be inconvenient. I agree. It is currently INFO because you often need statistics in production (when DEBUG would likely be switched off). I think we should add a configuration property called statistics-log-level. And if you don't define it then nothing gets logged at all. > Of course the customization requires from user to use pool facade > directly. Not true. At least, if I understand you correctly. You can configure Proxool using a Properties object sent to the Driver. It is the clumsiest way of configuring it but it is there for precisely that reason. [The JAXPConfigurator is the nicest way :)] > I would recomьend to make a wrapper around pool facade reinitializing > the pool on getting servlet events. But then what API does the wrapper adhere to? Is there a spec. for servlets doing this? > I am sorry for such a long essay I welcome it. Keep it up, Andrew. Out of our differences and misunderstandings will rise a better Proxool :) -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Andrew B. <ne...@my...> - 2003-02-05 00:15:06
|
Hello all, I will not quote any messages but I am going to comment few. I would divide the problems on few groups: 1. Default pool behaviour 2. Work-arounds for JVMs that are not fully compatible or just obsolet 3. Pool customization 1. Default pool behaviour=20 Pool is an underlying subsystem or component serving in between of an exter= nal data storage and application business logic (ABL). To be more precise= not the ABL itself but some abstraction layer that is responsible for da= ta supplying. Normally, the ABL should not even suspect the existence of = the pool. That's why the pool's behaviour should be transparent as much a= s possible. As an example I would refer Garbage Collection. We can run it= in some particular cases but there is no need to call it in average case= .=20 2. Work-arounds for JVMs that are not fully compatible or just obsolet The design of the pool should rely upon recent feature list to reduce code= overhead unless feature causes malfuction of the pool. If JVM is not ful= ly compatible the work-around should be offered to simulate normal behavi= our of the pool. It is bad idea to hardcode such work-arounds. It causes = unpredictable code behaviour. In our case for all JVMs which doesn't exec= ute shutdownHook should be used facade's method like shutdownPool() havin= g empty signature. The name of such method must correspond to action sema= ntics.=20 3. Pool customization Since I have declared the default pool behaviour it is time to say how to c= onfigure the pool. This topic is pretty wide and I will try to concentrat= e just on few spots. These are: =093.1 Pool parameter set=09 =09It includes all parameters impacting pool resource consuming in wide sen= se of resource term. I mean how many connections are prototyped, how ofte= n watchdog process is forked, etc.=20 =093.2 Pool diagnostics=20 =09This class of options doesn't impact resource consuming but let nest the= pool into custom framework. For example, currently the pool provides sta= tistics with INFO log message type. In some cases it might be inconvenien= t. May be it is possible to change I have not tried yet but indeed it mus= t be changable. =09Of course the customization requires from user to use pool facade direct= ly. Being a reusable component, the pool provides API to be managed. Use = of the component is a matter of framework. In our case, Tomcat is sort of= framework. I would recom=D1=8Cend to make a wrapper around pool facade r= einitializing the pool on getting servlet events. It's not responsibility= of the pool to know Tomcat or Tomouse being using it. I am sorry for such a long essay however may be you fing it useful. If you = have any questions or doubts you are welcome to [nm]ail me ;) Regards, Andrew. =09 |
|
From: Bill H. <bi...@lo...> - 2003-02-04 23:08:51
|
On Tue, 2003-02-04 at 22:10, Christian Nedregård wrote: > We should not depend on finalizers at all. We don't. The finalizer call the "shutdown code", as does the ShutdownHook, as does ProxoolFacade.removeAllConnectionPools. > People that use a JVM that does not implement the hook properly will > just have to live with the unclean shutdown I guess :( Yep. > Both the housekeeper thread and the prototyping thread are run as > daemons so they should not cause any additional problems on shutdown. There's also a Monitor thread that logs statistics (if you configure some statistics). But that's a daemon too, I just thought I'd mention it for completeness. > The real problem is shutting down the pool on application reloads. Yes, we need to be clear about that. It is *almost* a separate problem. > We also need to be sure that shutting down Proxool several times in a row > does not cause problems. In a servlet container for example, > Servlet.destroy() will shutdown Proxool first, and then the shutdown hook > will do it again. It copes with that. You get a short debug message in the log saying something like "Ignoring duplicate attempt to shutdown pool". -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: <chr...@em...> - 2003-02-04 22:11:51
|
We should not depend on finalizers at all. As you have mentioned it might
never get called, and if it does get called you don't have any control in
wich order they are called.
The 1.3+ code should implement the shutdown hook. People that use a JVM that
does not implement the hook properly will just have to live with the unclean
shutdown I guess :( Both the housekeeper thread and the prototyping thread
are run as daemons so they should not cause any additional problems on
shutdown.
The real problem is shutting down the pool on application reloads. Our
current implementation of this has been proved to be very unpredicable, so I
think we need to document *very clearly* that all applications that expect
to be reloaded must shutdown proxool in some kind of container spesific
manner. As you mention, Servlet.destroy() is a good place to do this in a
servlet container. Most other environments will hopefully also provide
something similar (like Disposable.dispose() in a Avalon container).
We also need to be sure that shutting down Proxool several times in a row
does not cause problems. In a servlet container for example,
Servlet.destroy() will shutdown Proxool first, and then the shutdown hook
will do it again.
CHR
> -----Original Message-----
> From: pro...@li...
> [mailto:pro...@li...]On Behalf Of Bill
> Horsman
> Sent: 04 February 2003 18:17
> To: Proxool Developer List
> Subject: Re: [Proxool-developer] Bug 673073
>
>
> Hi all,
>
> A further twist: my tests with Tomcat show that the ShutdownHook works
> fine when you shutdown Tomcat. But if you simply touch the web.xml this
> causes the application to be restarted. The Servlet's destroy() method
> is called but not the ShutdownHook (which is as you might expect since
> the JVM isn't shutting down).
>
> As a consequence, it might make sense, for some people to use:
>
> public void destroy() {
> ProxoolFacade.removeAllConnectionPools(0);
> }
>
> as well.
>
> Fortunately, when you do eventually shutdown Tomcat then all the hooks
> are run so everything is eventually cleaned up. The only problem is that
> you might have more pools running than you think.
>
> > 1- Not all VM implementations apparently support the shutdownHook
> > properly. I do not have any solid evidence to this available, but this
> > is what I know I've read in places before.
>
> Maybe it is a FAQ. Q. "I have stopped my application but Proxool keeps
> running". A. "Shutdown manually."
>
> > 3- Perhaps for versions -1.3 to use this Runtime.runFinalizersOnExit
>
> But it's deprecated because it is unsafe. We *could* do that, or we
> could just advise JDK < 1.3 users to finalize manually.
>
> --
> Bill Horsman
> Proxool
> http://proxool.sourceforge.net
> ICQ: 119577180
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
|
|
From: Bill H. <bi...@lo...> - 2003-02-04 17:17:13
|
Hi all,
A further twist: my tests with Tomcat show that the ShutdownHook works
fine when you shutdown Tomcat. But if you simply touch the web.xml this
causes the application to be restarted. The Servlet's destroy() method
is called but not the ShutdownHook (which is as you might expect since
the JVM isn't shutting down).
As a consequence, it might make sense, for some people to use:
public void destroy() {
ProxoolFacade.removeAllConnectionPools(0);
}
as well.
Fortunately, when you do eventually shutdown Tomcat then all the hooks
are run so everything is eventually cleaned up. The only problem is that
you might have more pools running than you think.
> 1- Not all VM implementations apparently support the shutdownHook
> properly. I do not have any solid evidence to this available, but this
> is what I know I've read in places before.
Maybe it is a FAQ. Q. "I have stopped my application but Proxool keeps
running". A. "Shutdown manually."
> 3- Perhaps for versions -1.3 to use this Runtime.runFinalizersOnExit
But it's deprecated because it is unsafe. We *could* do that, or we
could just advise JDK < 1.3 users to finalize manually.
--
Bill Horsman
Proxool
http://proxool.sourceforge.net
ICQ: 119577180
|
|
From: Martin C. <mus...@us...> - 2003-02-04 15:50:26
|
On Tue, 2003-02-04 at 10:36, Bas Cancrinus wrote: > Bill Horsman wrote: > > We have not found any robust way of determining when the application has > > ended. Any suggestions are welcome. > > Runtime.addShutdownHook() is the key (JRE 1.3+). Shutdown hooks are > always executed by the VM, no matter how it exits. The only drawback is > an extra permission when the app is forked: > > permission java.lang.RuntimePermission "shutdownHooks"; > > According to the discussions at the JDC it is never guaranteed that the > VM executes finalize(), whereas it is for shutdown hooks - I confirm > this by my own practice. A few notes: 1- Not all VM implementations apparently support the shutdownHook properly. I do not have any solid evidence to this available, but this is what I know I've read in places before. 2- http://java.sun.com/j2se/1.4.1/docs/guide/lang/hook-design.html Is a good place to look at. 3- Perhaps for versions -1.3 to use this Runtime.runFinalizersOnExit Martin |
|
From: Bas C. <ba...@ci...> - 2003-02-04 15:37:54
|
Bill Horsman wrote: > We have not found any robust way of determining when the application has > ended. Any suggestions are welcome. Runtime.addShutdownHook() is the key (JRE 1.3+). Shutdown hooks are always executed by the VM, no matter how it exits. The only drawback is an extra permission when the app is forked: permission java.lang.RuntimePermission "shutdownHooks"; According to the discussions at the JDC it is never guaranteed that the VM executes finalize(), whereas it is for shutdown hooks - I confirm this by my own practice. Kind regards, Bas -- Bas Cancrinus -> ba...@ci... Software Architect Cipherware Ltd. -> http://www.cipherware.com |
|
From: Bill H. <bi...@lo...> - 2003-02-04 15:11:59
|
Welcome Andrew, On Tue, 2003-02-04 at 14:43, Andrey Budarevsky wrote: > You have to take a look at shutdown hook closely (sorry for > unexpected pun :)). You can setup a system-wide shutdown > action by means of registering a hook thread. It may help to > make Proxool's use more transparent. Please refer > Runtime.addShutdownHook at javadoc manual. Yes, I just found that. It is introduced in JDK 1.3 but I think we should include it Proxool. The JDK 1.2 code will have to omit it and it is up to JDK 1.2 users to manually finalize Proxool. I have done some limited tests with JUNit and the hook does close down the pool as expected. Other tests with other environments would be good. I'll do a test in Tomcat next. The new ShutdownHook code is committed in CVS version. (We can always remove it if it causes any problems). The 1.2 code (in src/java-jdk1.2) has it disabled. -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Andrey B. <ne...@my...> - 2003-02-04 14:45:03
|
Hi Everybody! I don't know if I need to repeat what I had told to Bill according to = pool management. Just to give a clue to the others: =20 Bill, You have to take a look at shutdown hook closely (sorry for=20 unexpected pun :)). You can setup a system-wide shutdown=20 action by means of registering a hook thread. It may help to=20 make Proxool's use more transparent. Please refer=20 Runtime.addShutdownHook at javadoc manual.=20 regards, Andrew. ---------------------------------------------------------------------- Comment By: Bill Horsman (billhorsman) Date: 2003-02-04 12:14 Message: Logged In: YES=20 user_id=3D91747 Hi Andrew, I take your point. I don't like having code call the Proxool API directly. I would really like to come up with a transparent solution to this. Actually, Proxool already overrides the finalize method, but in my experience this doesn't always get called. I suspect that calling System.exit() means that it doesn't get called. We really need to do some more investigation into this to determine exactly what circumstances cause what behaviour. I think we need to read the specs a bit more closely and then do some testing. It would be nice to know exactly what the problem is.=20 We have not found any robust way of determining when the application has ended. Any suggestions are welcome.=20 ---------------------------------------------------------------------- Comment By: Andrew S. Budarevsky (trex) Date: 2003-02-04 10:20 Message: Logged In: YES=20 user_id=3D44856 Hello Bill! Thank you for the advising. It is worth. However I would say=20 that it breaks the general concept of proxool to be a=20 transparent driver's proxy. I know it happens due to leak of=20 virtual machine state events. Oops... What about a finalize=20 method? Could it be possible to close pools on finalizing?=20 Andrew. |
|
From: Andrey B. <ne...@my...> - 2003-02-04 14:43:45
|
Hi Everybody! I don't know if I need to repeat what I had told to Bill according to = pool management. Just to give a clue to the others: =20 Bill, You have to take a look at shutdown hook closely (sorry for=20 unexpected pun :)). You can setup a system-wide shutdown=20 action by means of registering a hook thread. It may help to=20 make Proxool's use more transparent. Please refer=20 Runtime.addShutdownHook at javadoc manual.=20 regards, Andrew. ---------------------------------------------------------------------- Comment By: Bill Horsman (billhorsman) Date: 2003-02-04 12:14 Message: Logged In: YES=20 user_id=3D91747 Hi Andrew, I take your point. I don't like having code call the Proxool API directly. I would really like to come up with a transparent solution to this. Actually, Proxool already overrides the finalize method, but in my experience this doesn't always get called. I suspect that calling System.exit() means that it doesn't get called. We really need to do some more investigation into this to determine exactly what circumstances cause what behaviour. I think we need to read the specs a bit more closely and then do some testing. It would be nice to know exactly what the problem is.=20 We have not found any robust way of determining when the application has ended. Any suggestions are welcome.=20 ---------------------------------------------------------------------- Comment By: Andrew S. Budarevsky (trex) Date: 2003-02-04 10:20 Message: Logged In: YES=20 user_id=3D44856 Hello Bill! Thank you for the advising. It is worth. However I would say=20 that it breaks the general concept of proxool to be a=20 transparent driver's proxy. I know it happens due to leak of=20 virtual machine state events. Oops... What about a finalize=20 method? Could it be possible to close pools on finalizing?=20 Andrew. |
|
From: Bill H. <bi...@lo...> - 2003-02-04 12:21:56
|
Hi all, There has been a lot of activity on bug 673073 recently. It's all to do with finalization of the house keeper and prototyper threads when the application ends. This is the transcript: --- Date: 2003-01-23 13:41 Sender: trex Logged In: YES user_id=44856 First I must to say that the implementation of this pool is very robust and high quality. However I have encountered the following problems using the pool. Connection c = DriverManager.getConnection( "proxool.alias:sun.jdbc.odbc.JdbcOdbcDriver:jdbc:odbc:test","",""); md = c.getMetaData(); // using metadata // getting the connection back to the pool md.getConnection().close() //!!!!!!!!!!!!!!!!!!!!!!!!!!!!! the line above will not bring the connection up to the pool. It just closes it messing the stuff. I know it is always possible to avoid this. Finally, I have solved this problem but the listening to the real connection state would be really nice feature to have. I mean if the pool would be able to listen to the connection state and prevent it from misusinng. Andrew S. Budarevsky --- Date: 2003-01-24 10:06 Sender: billhorsman Logged In: YES user_id=91747 Andrew, Hmm, that's interesting. I see the problem, but I'm not sure of the best way to solve it. I think the only way is to proxy the DatabaseMetaData object and override the getConnection() method. The problem is that the Connection interface doesn't provide any hooks with which to listen to a connection. Hmm. I will add a FAQ describing this problem and schedule a task to fix this. Thanks for spotting such an obscure problem! Regards, Bill --- Date: 2003-01-31 17:47 Sender: billhorsman Logged In: YES user_id=91747 I have fixed this by proxying DatabaseMetaData too. It is will be in version 0.7 (due February 5th) or you can get the latest from CVS. --- Date: 2003-02-03 12:38 Sender: trex Logged In: YES user_id=44856 Hello Bill! Good work! Though I won't change my framework to apply the newest stuff for awhile I would suject that it might help to anybody else. What I wanted to tell you more is that it seems the pool does not let application quit by means of holding a running thread. But I am not sure yet. At the moment I have System.exit executed on QUIT event. Within few days I am going to check that and inform you as soon as I have something to tell you for sure. Andrew --- Date: 2003-02-03 17:06 Sender: billhorsman Logged In: YES user_id=91747 Hi Andrew, You should call ProxoolFacade.removeAllConnectionPools(delay) when you quit. This will close all connections gracefully and kill all the threads that are running. We can't think of a way of ensuring this happens automatically. The delay is the amount of time (milliseconds) that you are prepared to wait for connections to stop being active before closing them anyway. Hope this helps, Bill --- Date: 2003-02-04 10:20 Sender: trex Logged In: YES user_id=44856 Hello Bill! Thank you for the advising. It is worth. However I would say that it breaks the general concept of proxool to be a transparent driver's proxy. I know it happens due to leak of virtual machine state events. Oops... What about a finalize method? Could it be possible to close pools on finalizing? I can explain why I am so concerned of the trasparency. I am working on a framework that manages application data flows, called streams. Database is one of data sources. In my case the data source is not a driver of database or similar. It could be something very very abstract entity resembling data source behaviour. I don't think I even need to have a method closing the end point. I would prefer to rely on system-wide finalization in case of Java. It's not requirement, it's a feature. Few years ago I have implemented a pool of tcp connections resided on servlet and connected to application server. I don't remeber but it seems I closed connections by means of overriding finalize method. What would you say? Andrew. --- Date: 2003-02-04 12:14 Sender: billhorsman Logged In: YES user_id=91747 Hi Andrew, I take your point. I don't like having code call the Proxool API directly. I would really like to come up with a transparent solution to this. Actually, Proxool already overrides the finalize method, but in my experience this doesn't always get called. I suspect that calling System.exit() means that it doesn't get called. We really need to do some more investigation into this to determine exactly what circumstances cause what behaviour. I think we need to read the specs a bit more closely and then do some testing. It would be nice to know exactly what the problem is. We have not found any robust way of determining when the application has ended. Any suggestions are welcome. --- I have suggested to Andrew that he continues this discussion on this list so that we can all get involved. Regards, -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Bas C. <ba...@ci...> - 2003-02-03 13:39:49
|
Bill Horsman wrote: > "I tried to figure out what the smart thing about > proxool is, except for providing a pool for a > non-pooled driver." > > Can anyone help me out here? I think Proxool is very stable and robust > but it's hard to measure that quantatively against other pools. 1. Proxool's liberal license (Apache) allows free commercial and non-commercial distribution, so it serves all ISV business models. 2. Proxool is a true wrapper driver, which implies that it a) protects previous investments in JDBC drivers and b) ensures compatibility with the J2SE API. We can provide an objective performance benchmark when the J2EE CTS passes. Al is ill at the moment, I hope he can provide us with more details on this later this week. Kind regards, Bas -- Bas Cancrinus -> ba...@ci... Software Architect Cipherware Ltd. -> http://www.cipherware.com |
|
From: Bill H. <bi...@lo...> - 2003-02-02 23:49:39
|
Hi all, We've had a documentation "bug" since November (#644080). It says: "I tried to figure out what the smart thing about proxool is, except for providing a pool for a non-pooled driver." Can anyone help me out here? I think Proxool is very stable and robust but it's hard to measure that quantatively against other pools. We do have an API that allows you to monitor the performance of the pool; even timing each transaction if that's what you want. And with the new MonitorServlet you can get access to that information very easily. Is there anything else we should be shouting about? How about ease of configuration? -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Bill H. <bi...@lo...> - 2003-01-31 18:05:33
|
Hi all, Does anyone have any feelings on how soon to release 0.7? Already ready is: - JDK 1.2 working code - brought up to date the 1.2 "patch" now passes all the tests. The patch works within Ant by replacing 8 classes from the src/java-jdk1.2 path. Mostly to do with the Proxy code but also some small things like a Timer and image writing in the new monitor. My philosophy here is to not let JDK 1.2 influence how we design Proxool too much. - MonitorServlet - a new cool servlet to provide information about running pools. See here for screenshot: http://proxool.sourceforge.net/dev/monitor.html - DatabaseMetaData - fix for bug 673073 http://sourceforge.net/tracker/index.php?func=detail&aid=673073&group_id=53958&atid=472195 Christian is working on new listener code so that we can handle multiple listeners per pool. Should be ready by Monday. Other stuff in the pipeline is the conversion of the documentation into DocBook format. Christian and Martin are working on that. I would think we would include this in 0.8. Bas and Alastair will be working on J2EE compliance as soon as their workload allows. --- Does anyone have any feedback on the rate of releases? Too slow? Too fast? Anybody want to influence what will be included before 1.0? I did wonder about producing snapshots. That is, releases like 0.6.1. They would be hidden and only available on the /dev web pages. The normal release history would go something like: 0.6 (full release) 0.6.1 (hidden) 0.6.2 (hidden) 0.7 (full release) -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
