The URL is interpreted by the JDBC driver / database. If you take a look at the database documentation even tilde ~ is suggested. Otherwise the database is relative to the working directory
http://www.h2database.com/html/cheatSheet.html However this has got nothing to do with my issue which is only apparent on postgresql and now H2. I had a look at the article you posted a link to. I am using JSTL <SQL> statements which use the datasource and otherwise an hibernate entitymanager. I guess it could be that I missed an entityManager.close somewhere, yet I do apply the same close handling with try catch finally suggested by your article. I was hoping that the logAbandoned flag would produce any warnings, however so far I have not seen anything. It's also strange that this is only apparent on PostgreSQL and not H2. It could well be that H2 is more forgiving to unclosed connections though. Thanks again for all your suggestions. Alex On 3 Feb 2010, at 00:15, Caldarale, Charles R wrote: >> From: Alexander Hartner [mailto:a...@j2anywhere.com] >> Subject: Re: Active DataSource Connection count never decreasing with >> PostgreSQL >> >>> Put this into either META-INF/context.xml within your WAR/webapp >>> directory, or into CATALINA_BASE/Catalina/[hostname]/ROOT.xml >>> >>> Remove the "path" and "docBase" attributes when you move the >>> <Context> element. >> >> I really like it that way as it allows me to configure what I need to >> in one central place without having to touch or expand the WAR file. > > And it breaks things. You are now getting double deployment, once under the > name AddressBookServer and once again as ROOT. Do it the right way, by > renaming your .war file to ROOT.war, and placing the <Context> element in > conf/Catalina/[host]/ROOT.xml - that also avoids having to change the > contents of the .war file. (Note that Chris' suggesting was missing part of > the path.) As Chris said, when you do that, remove the path and docBase > attributes. > >> This also works great for me. My database folder is relative the the >> startup script. > > That's really asking for trouble. A parser has complete freedom to ignore > any .. entry in a URL, so if it happens to be working now, you're extremely > lucky, and there's no guarantee it will work tomorrow. The URL is *not* > relative to any current directory, since it doesn't target the file system > per se. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
