RE: C3P0 Connection pooling needed?
If running in embedded mode then don't worry too much about it. If in server mode then yes. -Original Message- From: Radim Kolar [mailto:h...@sendmail.cz] Sent: 19 November 2009 20:26 To: derby-user@db.apache.org Subject: C3P0 Connection pooling needed? I am using embedded derby 10.3. Is there need for C3P0 connection pool software because i am creating lot of short lived connections to database? -- View this message in context: http://old.nabble.com/C3P0-Connection-pooling-needed--tp26421467p26421467.ht ml Sent from the Apache Derby Users mailing list archive at Nabble.com. __ NOD32 4615 (20091117) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com
Re: C3P0 Connection pooling needed?
I am using embedded derby 10.3. Is there need for C3P0 connection pool software because i am creating lot of short lived connections to database? I vaguely remember an issue with C3PO, not sure if the interrupt issue described here could be a problem for you, or if it even was due to C3PO usage, but thought I'd mention it.. http://old.nabble.com/ERROR-08000:-Connection-closed-by-unknown-interrupt-td16060173.html Dag
Re: C3P0 Connection pooling needed?
If you're looking for a transaction aware connection pool, along with associated JTA transaction manager, I really like Bitronix (open source). C3P0 is not transaction aware. Brett Sent from my iPhone On Nov 21, 2009, at 3:46, dag.wan...@sun.com (Dag H. Wanvik) wrote: I am using embedded derby 10.3. Is there need for C3P0 connection pool software because i am creating lot of short lived connections to database? I vaguely remember an issue with C3PO, not sure if the interrupt issue described here could be a problem for you, or if it even was due to C3PO usage, but thought I'd mention it.. http://old.nabble.com/ERROR-08000:-Connection-closed-by-unknown-interrupt-td16060173.html Dag
C3P0 Connection pooling needed?
I am using embedded derby 10.3. Is there need for C3P0 connection pool software because i am creating lot of short lived connections to database? -- View this message in context: http://old.nabble.com/C3P0-Connection-pooling-needed--tp26421467p26421467.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: Pooling
Matt Doran wrote: Peter Ondruška wrote: Yes, Derby does not provide connection pool, pick your favourite (I can confirm c3p0 works very well for me). Peter We also use c3p0 with embedded derby, but it's mainly just our default configuration so if you switch our app over to a network based database you can take advantage of the pooling. When using embedded derby is there advantage (or disadvantage!) to using a DB connection pool? Hi Matt, I see some people claim c3p0 is a dead project. Does anyone know if this is the fact? From the SourceForge site I see that the last download was added in May 2007. Even though there hasn't been any releases lately, the project may still be of great use to people :) I also remember that some people had problems using a certain c3p0 version with Derby embedded because c3p0 used Thread.interrupt(). This caused Derby to abort writes (at least when using NIO). With the client driver, this isn't a problem. I'm not sure if this problem is present in the latest version of c3p0 (maybe one could do a quick scan of the source). Regards, -- Kristian Cheers, Matt
Pooling
Hi, Just to be sure - Derby does not directly support connection pooling, correct? Rather, One must use a third party pool such as Apache DBCP Could you please confirm my understanding? Thanks, chris
Re: Pooling
Yes, Derby does not provide connection pool, pick your favourite (I can confirm c3p0 works very well for me). Peter On Sun, Sep 27, 2009 at 11:56 PM, Christopher Giblin c...@zurich.ibm.comwrote: Hi, Just to be sure - Derby does not directly support connection pooling, correct? Rather, One must use a third party pool such as Apache DBCP Could you please confirm my understanding? Thanks, chris
Re: Pooling
Peter Ondruška wrote: Yes, Derby does not provide connection pool, pick your favourite (I can confirm c3p0 works very well for me). Peter We also use c3p0 with embedded derby, but it's mainly just our default configuration so if you switch our app over to a network based database you can take advantage of the pooling. When using embedded derby is there advantage (or disadvantage!) to using a DB connection pool? Cheers, Matt
Re: Embedded Derby + J2ME + JDBC Connection Pooling
Paul French [EMAIL PROTECTED] writes: Hello All, I create an EmbeddedSimpleDataSource in my code. My application is multi-threaded. I assume EmbeddedSimpleDataSource is thread safe from the point of view of obtaining connections. What is the cost of getting a connection each time I need to do some database work? (Derby is running embedded in my application) If the cost is high then I would like to use a light weight Connection Pool Manager similar to Apache Commons DBCP, any ideas of a good implementation that works on J2ME Personal Profile 1.1.2 Creating connections in embedded Derby is a very cheap operation compared to creating connections to a database server over the network, so you won't see the same performance improvements with connection pooling as in a traditional database environment. There is a one-time cost when you set up a connection (creating the connection object, transaction object, context stack, etc.) that you will save if you have a pool. Whether or not it's worth it depends on how frequently your application creates a new connection. If it does it once every five seconds, I doubt that you'll notice the difference. If it creates many connections (like tens or hundreds) per second, you'll be more likely to see an improvement. -- Knut Anders
RE: Embedded Derby + J2ME + JDBC Connection Pooling
Thanks, I'll try without a database connection pool for now. I will probably be in the order of 10 connections per second at peek. Cheers Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 09 October 2008 09:15 To: Derby Discussion Subject: Re: Embedded Derby + J2ME + JDBC Connection Pooling Paul French [EMAIL PROTECTED] writes: Hello All, I create an EmbeddedSimpleDataSource in my code. My application is multi-threaded. I assume EmbeddedSimpleDataSource is thread safe from the point of view of obtaining connections. What is the cost of getting a connection each time I need to do some database work? (Derby is running embedded in my application) If the cost is high then I would like to use a light weight Connection Pool Manager similar to Apache Commons DBCP, any ideas of a good implementation that works on J2ME Personal Profile 1.1.2 Creating connections in embedded Derby is a very cheap operation compared to creating connections to a database server over the network, so you won't see the same performance improvements with connection pooling as in a traditional database environment. There is a one-time cost when you set up a connection (creating the connection object, transaction object, context stack, etc.) that you will save if you have a pool. Whether or not it's worth it depends on how frequently your application creates a new connection. If it does it once every five seconds, I doubt that you'll notice the difference. If it creates many connections (like tens or hundreds) per second, you'll be more likely to see an improvement. -- Knut Anders __ NOD32 3505 (20081008) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com
Embedded Derby + J2ME + JDBC Connection Pooling
Hello All, I create an EmbeddedSimpleDataSource in my code. My application is multi-threaded. I assume EmbeddedSimpleDataSource is thread safe from the point of view of obtaining connections. What is the cost of getting a connection each time I need to do some database work? (Derby is running embedded in my application) If the cost is high then I would like to use a light weight Connection Pool Manager similar to Apache Commons DBCP, any ideas of a good implementation that works on J2ME Personal Profile 1.1.2 Thanks Paul
Re: temporary tables and connection pooling
Bob Durie wrote: Thanks for the comments! I wouldn't even know where to begin to implement a master procedure to do this work, efficiently anyways. I could name my tables in a known scheme, search the table lists, then drop if they exist, but that is computationally expensive. I think a better approach would be to do it in my java persistence layer, whenever I fetch a temp table, record the connection that got it, then when I give it back to the pool drop it by name. As for the ConnectionPoolDataSource - I didn't even know this existed!!! We are using physical/logical connections using org.apache.commons.pool.impl.GenericObjectPool and after a first glance it seems to be MUCH MORE feature rich, supporting testOnBorrow/Return, idle timeouts, maxActive, etc.. I may give this other pooling scheme a shot, but for fear its support may not be across the board for other db's (we also use SQL Server and Oracle) I will likely have to go with the track n slash approach. PLEASE correct me if you think I'm wrong here. At least for Derby, you still need a connection pool manager on top of the ConnectionPoolDataSource. This manager could provide the other functionality you refer to. Note that to get a connection intended for pooling, you must call 'getPooledConnection'. I don't have much hands-on experience with this, but I have been using ClientConnectionPoolDataSource with the Glassfish connection pool. There were some performance problems with the implementation, they have been fixed in the development versions by now. If you try it out, let us know how it goes :) hth, -- Kristian Bob [ snip ]
temporary tables and connection pooling
Hi, I have an application that uses JDBC, derby among one of the supported databases (I apologize that this is not 100% specific to derby!!). We use apache commons GenericObjectPool to pool our connections, hence they persist for a period of time. I want to add support for temporary tables into our persistence layer, but I'm getting stuck because of our pooling. We use a combination of transactional and auto-commit db accesses, so using ON COMMIT DELETE ROWS isn't really practical for the temp tables as the data won't be there if we're in auto-commit. Is there some way to issue a command to derby to flush its temp tables? Does anyone know of similar commands on other db's? I don't see how I can get this to work unless I simply use a random temporary table name for creation and then hope all the sessions eventually flush out (otherwise they may not ever get cleaned up and just accumulate forever...). The tables must be cleaned or guaranteed to not exist, otherwise subsequent borrowed sessions MAY have had that same table created before and still have old data. If anyone has thoughts or pointers on this subject I'd be very interested - a found a few threads on the subject: http://groups.google.com/group/comp.databases.informix/browse_thread/thr ead/159846150631624e http://osdir.com/ml/db.mysql.java/2003-10/msg00117.html Which seem to indicate my only recourse is to track connectionid-temptablelist and purge/truncate/drop the tables when I return the connection to the pool. I guess this will work but it seems laborious. Thanks for any help in advance!! Bob
Re: temporary tables and connection pooling
Hi Bob, I'm not aware of a master flush command in Derby. It may be useful to write your own flush() method which you can register as a Derby procedure and invoke at session boundaries. Depending on the Java support in the other databases you use, you may be able to register this method as a procedure in those databases too. Hope this helps, -Rick Bob Durie wrote: Hi, I have an application that uses JDBC, derby among one of the supported databases (I apologize that this is not 100% specific to derby!!). We use apache commons “GenericObjectPool” to pool our connections, hence they persist for a period of time. I want to add support for temporary tables into our persistence layer, but I’m getting stuck because of our pooling. We use a combination of transactional and auto-commit db accesses, so using “ON COMMIT DELETE ROWS” isn’t really practical for the temp tables as the data won’t be there if we’re in auto-commit. Is there some way to issue a command to derby to “flush” its temp tables? Does anyone know of similar commands on other db’s? I don’t see how I can get this to work unless I simply use a random temporary table name for creation and then hope all the sessions eventually flush out (otherwise they may not ever get cleaned up and just accumulate forever…). The tables must be cleaned or guaranteed to not exist, otherwise subsequent borrowed sessions MAY have had that same table created before and still have old data. If anyone has thoughts or pointers on this subject I’d be very interested – a found a few threads on the subject: http://groups.google.com/group/comp.databases.informix/browse_thread/thread/159846150631624e http://osdir.com/ml/db.mysql.java/2003-10/msg00117.html Which seem to indicate my only recourse is to track connectionid-temptablelist and purge/truncate/drop the tables when I return the connection to the pool. I guess this will work but it seems laborious. Thanks for any help in advance!! Bob
RE: temporary tables and connection pooling
Thanks for the comments! I wouldn't even know where to begin to implement a master procedure to do this work, efficiently anyways. I could name my tables in a known scheme, search the table lists, then drop if they exist, but that is computationally expensive. I think a better approach would be to do it in my java persistence layer, whenever I fetch a temp table, record the connection that got it, then when I give it back to the pool drop it by name. As for the ConnectionPoolDataSource - I didn't even know this existed!!! We are using physical/logical connections using org.apache.commons.pool.impl.GenericObjectPool and after a first glance it seems to be MUCH MORE feature rich, supporting testOnBorrow/Return, idle timeouts, maxActive, etc.. I may give this other pooling scheme a shot, but for fear its support may not be across the board for other db's (we also use SQL Server and Oracle) I will likely have to go with the track n slash approach. PLEASE correct me if you think I'm wrong here. Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 11:02 AM To: Derby Discussion Subject: Re: temporary tables and connection pooling Bob Durie skrev: Hi, I have an application that uses JDBC, derby among one of the supported databases (I apologize that this is not 100% specific to derby!!). We use apache commons GenericObjectPool to pool our connections, hence they persist for a period of time. I want to add support for temporary tables into our persistence layer, but I'm getting stuck because of our pooling. We use a combination of transactional and auto-commit db accesses, so using ON COMMIT DELETE ROWS isn't really practical for the temp tables as the data won't be there if we're in auto-commit. Is there some way to issue a command to derby to flush its temp tables? Does anyone know of similar commands on other db's? I don't see how I can get this to work unless I simply use a random temporary table name for creation and then hope all the sessions eventually flush out (otherwise they may not ever get cleaned up and just accumulate forever...). The tables must be cleaned or guaranteed to not exist, otherwise subsequent borrowed sessions MAY have had that same table created before and still have old data. Hello Bob, Maybe I have misunderstood what you want to achieve, but if you are using Derby's ConnectionPoolDataSource, I believe temporary tables are flushed/deleted when you create a new logical connection. The functionality is available inside Derby, but I don't think it is exposed to the end user (i.e. through JDBC or SQL). Also note that I don't think the client driver supports this in a Derby release yet, but it has been fixed in the latest development version (and on the dev 10.4 branch). Just to make it easy for you to determine if I have gotten this right, here's what I was thinking about. ConnectionPoolDataSource cpds = ... PooledConnection pc = cpds.getPooledConnection() // Hand this one out to the end user. Connection c1 = pc.getConnection() // Create temporary tables here. ... // When c1 is returned to the pool (or taken back forcibly), create a new logical connection for the next end user. Connection c2 = pc.getConnection() // All temporary tables created by c1 will be deleted here, even if they share the physical connection pc If you're pooling ordinary physical connections, this approach won't work. regards, -- Kristian If anyone has thoughts or pointers on this subject I'd be very interested - a found a few threads on the subject: http://groups.google.com/group/comp.databases.informix/browse_thread/thr ead/159846150631624e http://osdir.com/ml/db.mysql.java/2003-10/msg00117.html Which seem to indicate my only recourse is to track connectionid-temptablelist and purge/truncate/drop the tables when I return the connection to the pool. I guess this will work but it seems laborious. Thanks for any help in advance!! Bob
Re: embedded db and connection pooling
- Original Message - From: Robert J. Carr [EMAIL PROTECTED] To: Derby Discussion derby-user@db.apache.org Sent: Tuesday, June 03, 2008 9:04 PM Subject: Re: embedded db and connection pooling Hey Kristian- Thanks for the response, here's some comments: Do you delete the files on disk and connect to the same database (again), or are you creating a brand new database (with a different name / directory)? I will admit that what I was doing was illogical and I never should have expected it to work. I was basically deleting the database files between deployments of my web application. Since I switched to jndi data sources, where tomcat now owns the connection not my web app, this will no longer work. http://www.pinkdragon.net/doc_lib/contents/en/tomcat_6_0/jndi-resources-howto.html Robert, read the second paragraph... per webapp basis This is what I think... if its set up for a global resource TC thinks you using the dB across all webapps. So the pool is set up and remains setup even when a new webapp is added. In this case, deleting the dB and rebuilding is bad news because TC is still using it. But on a per webapp basis, you undeploy, do what you will, and on a redeploy, the connections a remade for that webapp only. It seems to just depent on whether you have the JNDI setup in sever.xml (global) or web-inf/context (webapp only) Have fun... ps if you want a independent dB pool... can steal the lib and demo code here --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm ---
Re: embedded db and connection pooling
Johnny Kewl wrote: Robert, read the second paragraph... per webapp basis This is what I think... if its set up for a global resource TC thinks you using the dB across all webapps. So the pool is set up and remains setup even when a new webapp is added. In this case, deleting the dB and rebuilding is bad news because TC is still using it. But on a per webapp basis, you undeploy, do what you will, and on a redeploy, the connections a remade for that webapp only. It seems to just depent on whether you have the JNDI setup in sever.xml (global) or web-inf/context (webapp only) From later in that document: -- Use of the JDBC Data Sources JNDI Resource Factory requires that you make an appropriate JDBC driver available to both Tomcat internal classes and to your web application. This is most easily accomplished by installing the driver's JAR file(s) into the $CATALINA_HOME/lib directory, which makes the driver available both to the resource factory and to your application. -- So even if the connection pool is per-app, it seems that the JDBC driver still needs to be installed globally. If you want to build a completely stand-alone webapp that starts up and shuts down Derby you need to provide your own connection pool. For an example, see the following: Start up shut down an embedded Derby instance: http://auth.opensolaris.org/svn/showfile.svn?path=%2ftrunk%2fAuthDb%2fsrc%2forg%2fopensolaris%2fauth%2fdb%2fDbManager.javarevision=HEADname=auth Stand-alone connection pool manager: http://auth.opensolaris.org/svn/showfile.svn?path=%2ftrunk%2fAuthDb%2fsrc%2forg%2fopensolaris%2fauth%2fdb%2fMiniConnectionPoolManager.javarevision=HEADname=auth Stand-alone DataSource: http://auth.opensolaris.org/svn/showfile.svn?path=%2ftrunk%2fAuthDb%2fsrc%2forg%2fopensolaris%2fauth%2fdb%2fDbDataSource.javarevision=HEADname=auth Tomcat infrastructure needed to start/stop Derby create/destroy the connection pool: http://auth.opensolaris.org/svn/showfile.svn?path=%2ftrunk%2fAuthWebapp%2fsrc%2fjava%2forg%2fopensolaris%2fauth%2fwebapp%2fservlet%2fAuthListener.javarevision=HEADname=auth -- Alan Burlison --
Re: embedded db and connection pooling
- Original Message - From: Alan Burlison [EMAIL PROTECTED] To: Derby Discussion derby-user@db.apache.org Sent: Wednesday, June 04, 2008 3:07 PM Subject: Re: embedded db and connection pooling Johnny Kewl wrote: Robert, read the second paragraph... per webapp basis This is what I think... if its set up for a global resource TC thinks you using the dB across all webapps. So the pool is set up and remains setup even when a new webapp is added. In this case, deleting the dB and rebuilding is bad news because TC is still using it. But on a per webapp basis, you undeploy, do what you will, and on a redeploy, the connections a remade for that webapp only. It seems to just depent on whether you have the JNDI setup in sever.xml (global) or web-inf/context (webapp only) From later in that document: -- Use of the JDBC Data Sources JNDI Resource Factory requires that you make an appropriate JDBC driver available to both Tomcat internal classes and to your web application. This is most easily accomplished by installing the driver's JAR file(s) into the $CATALINA_HOME/lib directory, which makes the driver available both to the resource factory and to your application. -- So even if the connection pool is per-app, it seems that the JDBC driver still needs to be installed globally. Alan... actually Robert if you try it and it does work on web-app basis, give us some feedback ;) I'm not sure if the driver makes any diffs, as long as when you undeploy the web app, TC lets the dB go, and when you redeploy that web app it makes the new connection pool, I'm not sure the driver makes any diffs. I'm guessing... but I think the core issue is to stop TC making those connections when it starts, ie it must not be global, because then it holds the connections for other webapps. If the driver remains visible... not sure if thats a problem, its just a library in a classpath? Maybe? Have to agree with the idea of independent pools, have always preferred the extra control that gives one. --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm ---
Re: embedded db and connection pooling
Johnny Kewl wrote: I'm not sure if the driver makes any diffs, as long as when you undeploy the web app, TC lets the dB go, and when you redeploy that web app it makes the new connection pool, I'm not sure the driver makes any diffs. I'm guessing... but I think the core issue is to stop TC making those connections when it starts, ie it must not be global, because then it holds the connections for other webapps. If the driver remains visible... not sure if thats a problem, its just a library in a classpath? The issue is that you don't have a truly 'stand alone, drop in deploy' webapp if it requires you to install stuff into the container's lib directory and fiddle with the server.xml file before deploying the app. -- Alan Burlison --
Re: embedded db and connection pooling
- Original Message - From: Alan Burlison [EMAIL PROTECTED] To: Derby Discussion derby-user@db.apache.org Sent: Wednesday, June 04, 2008 4:23 PM Subject: Re: embedded db and connection pooling Johnny Kewl wrote: I'm not sure if the driver makes any diffs, as long as when you undeploy the web app, TC lets the dB go, and when you redeploy that web app it makes the new connection pool, I'm not sure the driver makes any diffs. I'm guessing... but I think the core issue is to stop TC making those connections when it starts, ie it must not be global, because then it holds the connections for other webapps. If the driver remains visible... not sure if thats a problem, its just a library in a classpath? The issue is that you don't have a truly 'stand alone, drop in deploy' webapp if it requires you to install stuff into the container's lib directory and fiddle with the server.xml file before deploying the app. Ah, yes true, can make the webapp pools redeployable, but what do you do for the first webapp, and the server setup. You right, JNDI and embedded database are actually contradictory idea's, as far as plug and play goes. Thanks
Re: embedded db and connection pooling
Robert J. Carr wrote: I just set up connection pooling with an embedded derby database and it works great. I use derby in development and frequently destroy my database (delete it) and create anew. But now that I've been using connection pooling, it seems tomcat is holding onto some old version of my database in memory and not looking at this newly created (and empty) one. Is my only solution to restart tomcat each time I recreate my db? Before I started connection pooling I would just redeploy my webapp, but this now gets me into problems. Ideas? Hi Robert, It is a bit unclear to me what you are actually doing. Do you delete the files on disk and connect to the same database (again), or are you creating a brand new database (with a different name / directory)? In any case, I suspect you have to redeploy your data source; close all open connections and connection again. Maybe this is something your connection pool manager can do, or maybe you have to issue a redeploy command for Tomcat? Also, which OS and file system are you running on? regards, -- Kristian Thanks!
Re: embedded db and connection pooling
Hey Kristian- Thanks for the response, here's some comments: Do you delete the files on disk and connect to the same database (again), or are you creating a brand new database (with a different name / directory)? I will admit that what I was doing was illogical and I never should have expected it to work. I was basically deleting the database files between deployments of my web application. Since I switched to jndi data sources, where tomcat now owns the connection not my web app, this will no longer work. In any case, I suspect you have to redeploy your data source; close all open connections and connection again. Maybe this is something your connection pool manager can do, or maybe you have to issue a redeploy command for Tomcat? Right ... I guess this is what I was asking, is how to do this, assuming this is my only alternative (which I'm pretty sure it is at this point). Also, which OS and file system are you running on? OSX.5 and HFS+. Thanks- Robert
embedded db and connection pooling
I just set up connection pooling with an embedded derby database and it works great. I use derby in development and frequently destroy my database (delete it) and create anew. But now that I've been using connection pooling, it seems tomcat is holding onto some old version of my database in memory and not looking at this newly created (and empty) one. Is my only solution to restart tomcat each time I recreate my db? Before I started connection pooling I would just redeploy my webapp, but this now gets me into problems. Ideas? Thanks!
Re: embedded db and connection pooling
- Original Message - From: Robert J. Carr [EMAIL PROTECTED] To: Derby Discussion derby-user@db.apache.org Sent: Monday, June 02, 2008 10:02 PM Subject: embedded db and connection pooling I just set up connection pooling with an embedded derby database and it works great. I use derby in development and frequently destroy my database (delete it) and create anew. But now that I've been using connection pooling, it seems tomcat is holding onto some old version of my database in memory and not looking at this newly created (and empty) one. Is my only solution to restart tomcat each time I recreate my db? Before I started connection pooling I would just redeploy my webapp, but this now gets me into problems. Ideas? Robert I almost certain you can set it up on a per webapp basis... You going to have to look at your TC documentation or google. ie if the pool is just for a single webapp you can set it up that way. Probably do the context stuff in the app and not for the server etc, but check out the tc doca and google. I have my own pools so not practised... but its do-able --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm ---
Re: Derby, connection pooling and shutdown
Daniel Noll wrote: Hi all. At present I'm using Connection directly. After I close it, if it's the last connection open to the database I am doing a ;shutdown=true to force Derby to properly close it. Now I'm changing things to use connection pooling to make things go smoother when multiple threads want to do queries at the same time. Supposing I use an EmbeddedConnectionPoolDataSource, do I still need to do any manual shutdown of the database after the connection pool manager is closed, or is that all managed inside the ConnectionPoolDataSource implementation? Hi Daniel, Unless your connection pool manager does an explicit shutdown, you will have to do it manually. When I say have to, I mean you have to if you want to avoid doing recovery on the next boot of the database. Everything will work even if you don't shutdown properly, but you have to pay the cost of recovery at the next startup. It is of course considered good practice to shutdown properly, and it should be done if possible. regards, -- Kristian Daniel
Derby, connection pooling and shutdown
Hi all. At present I'm using Connection directly. After I close it, if it's the last connection open to the database I am doing a ;shutdown=true to force Derby to properly close it. Now I'm changing things to use connection pooling to make things go smoother when multiple threads want to do queries at the same time. Supposing I use an EmbeddedConnectionPoolDataSource, do I still need to do any manual shutdown of the database after the connection pool manager is closed, or is that all managed inside the ConnectionPoolDataSource implementation? Daniel
Re: ConnectionPoolDataSource - does it actually do pooling?
David Van Couvering wrote: I could check this out myself, but time is limited, and I thought someone might have a quick answer. On the Phobos (JavaScript in Glassfish) email list, the following statement is made: in Apache Derby there is a regular data source class (org.apache.derby.jdbc.ClientDataSource) which does not pool connections, but there's also a data source class with connection pooling (org.apache.derby.jdbc.ClientConnectionPoolDataSource). In the preconfigured Phobos data sources we use the latter, so connection pooling is on by default I thought ConnectionPoolDataSource *enabled* pooling but did not actually *do* it. Does it actually do connection pooling? No. I haven't checked this lately, but I can't remember any activity in this area. You will need a connection pool from elsewhere. I am not familiar with connection pool products, but I know Apache has an initiative; Commons DBCP. I do not know if this is ready-to-go, or just a framework to write your own. Does anyone have more information on this? regards, -- Kristian Thanks, David
Re: ConnectionPoolDataSource - does it actually do pooling?
Thanks, Kristian. I checked the DBCP site. It does appear to be a fully functioning connection pool that can work with a container or outside of a container. David On 7/24/07, Kristian Waagan [EMAIL PROTECTED] wrote: David Van Couvering wrote: I could check this out myself, but time is limited, and I thought someone might have a quick answer. On the Phobos (JavaScript in Glassfish) email list, the following statement is made: in Apache Derby there is a regular data source class (org.apache.derby.jdbc.ClientDataSource) which does not pool connections, but there's also a data source class with connection pooling (org.apache.derby.jdbc.ClientConnectionPoolDataSource). In the preconfigured Phobos data sources we use the latter, so connection pooling is on by default I thought ConnectionPoolDataSource *enabled* pooling but did not actually *do* it. Does it actually do connection pooling? No. I haven't checked this lately, but I can't remember any activity in this area. You will need a connection pool from elsewhere. I am not familiar with connection pool products, but I know Apache has an initiative; Commons DBCP. I do not know if this is ready-to-go, or just a framework to write your own. Does anyone have more information on this? regards, -- Kristian Thanks, David
ConnectionPoolDataSource - does it actually do pooling?
I could check this out myself, but time is limited, and I thought someone might have a quick answer. On the Phobos (JavaScript in Glassfish) email list, the following statement is made: in Apache Derby there is a regular data source class (org.apache.derby.jdbc.ClientDataSource) which does not pool connections, but there's also a data source class with connection pooling (org.apache.derby.jdbc.ClientConnectionPoolDataSource). In the preconfigured Phobos data sources we use the latter, so connection pooling is on by default I thought ConnectionPoolDataSource *enabled* pooling but did not actually *do* it. Does it actually do connection pooling? Thanks, David
can we use derby embedded mode with application server and have pooling?
Hi Thank you for reading my post. I have a question which i am looking for more information for it. We have an application which need a database for its own metadata. we use another database for real data that customer input to application. my question is : can we use derby embedded mode inside an application server ? I mean, can we create a connection pool for embedded derby in application server console? will it cause problem for us ? Does derby embedded driver support XA ? Thanks
Re: can we use derby embedded mode with application server and have pooling?
This should work, and yes the embedded driver supports XA. David legolas wood wrote: Hi Thank you for reading my post. I have a question which i am looking for more information for it. We have an application which need a database for its own metadata. we use another database for real data that customer input to application. my question is : can we use derby embedded mode inside an application server ? I mean, can we create a connection pool for embedded derby in application server console? will it cause problem for us ? Does derby embedded driver support XA ? Thanks
Connection Pooling in client server setup
Derby docs show that in 10.0 connection pooling is supported only in embedded Derby driver. Support for connection pooling in client server setup is there in 10.1 But not much info is there in the docs. Like how to set minimum or maximum connections to be opened in the pool? Any other properties that Derby supports for connection pool in client server setup. thx __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Connection Pooling in client server setup
simmi iyer wrote: Derby docs show that in 10.0 connection pooling is supported only in embedded Derby driver. Support for connection pooling in client server setup is there in 10.1 But not much info is there in the docs. Like how to set minimum or maximum connections to be opened in the pool? Any other properties that Derby supports for connection pool in client server setup. Derby only provides an implementation of ConnectionPoolDataSource, it does not provide a connection pool manager. An application server such as WebSphere or Geronimo provides a connection pool manager which handles the actual pooling on top of Derby's ConnectionPoolDataSource. Thus the application server documents how to configure the pool. Derby follows the model described in Chapter 11 of JDBC 3.0 spec and shown well in figure 11.1. Dan.
Re: Sun 8.0.1 Appserver pooling
myrnap wrote:
Nat Gross wrote:
myrnap wrote:
Nat Gross wrote:
Hi;
Although I have no problems connecting to my new Derby, via jdbc, I
cannot get a 'ping' when setting up a j2ee pool and jndi connector
in the Sun app server. I followed the instructions on the java.net
blog,for embedded, the classpath is set, have tried various javax
connectors, the xa version and non xa version, to no avail.
Your help will be appreciated.
Thanks
-nat
Nat,
What's the error you see?
What's in the server.log?
Does a derby.log get created? If so, is it where you expect it to be?
Myrna
Progress For some reason the sdk's bin directory wasn't in the
PATH. I didn't dream that the gui admin uses the cmdline stuff behind
the scenes. Anyhow, now there is a new error when pinging.
The first exception sais that it couldn't open the database and the
next exception has the details why. But the next exception list some
gui framework error, for the ping button. Here it is.:
Hm, I like the classnot found problem more - at least then we know
it's the classpath, somehow. :-)
I would've checked whether derby.jar was in the lib, or lib/ext dir...
The 'Failed to start database ...' error can be caused by a number of
situations...Unfortunately, I think the app server gobbles up the
nested (i.e. 'next') exception...
Perhaps someone else knows more about the framework error...
The situation I'm thinking you might be hitting is somehow 2
jvms/processes trying to get hold of the same database.
In that case, you would see a derby.log that looks completely fine and
healthy (because of the first jvm starting the database), but still
get this error. And of course, you'd see an extra (java or javaw)
process after the ping.
To see more, I suggest you add the following derby.properties file to
the derby.system.home dir (practically speaking, that would be where
derby.log gets created.):
derby.infolog.append=true
derby.language.logStatementText=true
derby.stream.error.logSeverityLevel=0
If it is the multiple jvm situation, then you will see a neat starting
message in derby.log still get this error. If it's something else,
then possibly the database does not get opened at all, and your
derby.log would be an empty file even after infolog.append is picked
up from derby.properties.
Now, why there would be 2 jvms trying to start the database - I don't
know...Does the ping start a second process/jvm?
Another area to look at is the policy files. This is really a wild
guessBut make sure the following permissions are set for the derby
database:
grant codeBase file://your domain/lib dir/derby.jar {
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission derby.*, read;
permission java.io.FilePermission ${derby.system.home}${/} -,
read,write,delete;
I hope this helps any
Myrna
Thank you much. I am sure that this is a bug on the Sun Appserver 8.0.1.
A search of the Sun forum revealed that many users have seen the same
Sun error with other products (non-Derby, or even db related). So, I
guess I'll try their RC of the next version, to verify this. I am also
thinking of using the Jonas (objectweb.org) appserver, but I don't know
how to embed Derby within it.
If anyone has used Jonas replacing HSQLDB (that comes with it) with
Derby, please let me know.
TA
-nat
Re: Sun 8.0.1 Appserver pooling
Nat,
I have had this working successfully with 8.0 and early beta of 8.1.
Where did you install your derby classes? Normally I put them in
domains/domain1/lib/ext.
Can you post your domain.xml entry that you used with the embedded
driver? Are you sure you did not have another process that already had
the DB open outside of SJSAS?
Regards
Lance
Nat Gross wrote:
myrnap wrote:
Nat Gross wrote:
myrnap wrote:
Nat Gross wrote:
Hi;
Although I have no problems connecting to my new Derby, via jdbc,
I cannot get a 'ping' when setting up a j2ee pool and jndi
connector in the Sun app server. I followed the instructions on
the java.net blog,for embedded, the classpath is set, have tried
various javax connectors, the xa version and non xa version, to no
avail.
Your help will be appreciated.
Thanks
-nat
Nat,
What's the error you see?
What's in the server.log?
Does a derby.log get created? If so, is it where you expect it to be?
Myrna
Progress For some reason the sdk's bin directory wasn't in the
PATH. I didn't dream that the gui admin uses the cmdline stuff
behind the scenes. Anyhow, now there is a new error when pinging.
The first exception sais that it couldn't open the database and the
next exception has the details why. But the next exception list some
gui framework error, for the ping button. Here it is.:
Hm, I like the classnot found problem more - at least then we know
it's the classpath, somehow. :-)
I would've checked whether derby.jar was in the lib, or lib/ext dir...
The 'Failed to start database ...' error can be caused by a number of
situations...Unfortunately, I think the app server gobbles up the
nested (i.e. 'next') exception...
Perhaps someone else knows more about the framework error...
The situation I'm thinking you might be hitting is somehow 2
jvms/processes trying to get hold of the same database.
In that case, you would see a derby.log that looks completely fine
and healthy (because of the first jvm starting the database), but
still get this error. And of course, you'd see an extra (java or
javaw) process after the ping.
To see more, I suggest you add the following derby.properties file to
the derby.system.home dir (practically speaking, that would be where
derby.log gets created.):
derby.infolog.append=true
derby.language.logStatementText=true
derby.stream.error.logSeverityLevel=0
If it is the multiple jvm situation, then you will see a neat
starting message in derby.log still get this error. If it's
something else, then possibly the database does not get opened at
all, and your derby.log would be an empty file even after
infolog.append is picked up from derby.properties.
Now, why there would be 2 jvms trying to start the database - I don't
know...Does the ping start a second process/jvm?
Another area to look at is the policy files. This is really a wild
guessBut make sure the following permissions are set for the
derby database:
grant codeBase file://your domain/lib dir/derby.jar {
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission derby.*, read;
permission java.io.FilePermission ${derby.system.home}${/} -,
read,write,delete;
I hope this helps any
Myrna
Thank you much. I am sure that this is a bug on the Sun Appserver
8.0.1. A search of the Sun forum revealed that many users have seen
the same Sun error with other products (non-Derby, or even db
related). So, I guess I'll try their RC of the next version, to verify
this. I am also thinking of using the Jonas (objectweb.org) appserver,
but I don't know how to embed Derby within it.
If anyone has used Jonas replacing HSQLDB (that comes with it) with
Derby, please let me know.
TA
-nat
Re: Sun 8.0.1 Appserver pooling
myrnap wrote:
Nat Gross wrote:
Hi;
Although I have no problems connecting to my new Derby, via jdbc, I
cannot get a 'ping' when setting up a j2ee pool and jndi connector in
the Sun app server. I followed the instructions on the java.net
blog,for embedded, the classpath is set, have tried various javax
connectors, the xa version and non xa version, to no avail.
Your help will be appreciated.
Thanks
-nat
Nat,
What's the error you see?
An error has occurred.
Operation 'pingConnectionPool' failed in 'resources' Config Mbean.
Target exception message: Class name is wrong or classpath is not set
for : org.apache.derby.jdbc.EmbeddedXADataSource
Please note that the error is similar when I specify the non-xa
datasource (...embeddedDatasource).
Also very importantly the derby.jar is not only copied to the lib dir of
the domain, the classpath settings in the 'Application Server -- jvm
settings --classpath prefix is also set to point to derby.jar. (And
yes, the server has been restarted numerous times.)
What's in the server.log?
Sorry for the lengthy log, but ALL of the following was generated by the
one ping request: (Again, please excuse.)
#|2004-12-27T00:26:08.982-0500|SEVERE|sun-appserver-pe8.0.0_01|javax.enterprise.resource.resourceadapter|_ThreadID=12;|RAR5099
: Wrong class name or classpath for Datasource Object : {0}
java.lang.ClassNotFoundException: org.apache.derby.jdbc.EmbeddedXADataSource
at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
at
com.sun.gjc.common.DataSourceObjectBuilder.getDataSourceObject(DataSourceObjectBuilder.java:198)
at
com.sun.gjc.common.DataSourceObjectBuilder.constructDataSourceObject(DataSourceObjectBuilder.java:65)
at
com.sun.gjc.spi.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:71)
at
com.sun.enterprise.connectors.ConnectorConnectionPoolAdminServiceImpl.testConnectionPool(ConnectorConnectionPoolAdminServiceImpl.java:597)
at
com.sun.enterprise.connectors.ConnectorRuntime.testConnectionPool(ConnectorRuntime.java:520)
at
com.sun.enterprise.admin.mbeans.ResourcesMBean.pingConnectionPool(ResourcesMBean.java:1805)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:287)
at
com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:280)
at
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:221)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:228)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:823)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:54)
at $Proxy1.invoke(Unknown Source)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:282)
at
com.sun.enterprise.tools.admingui.util.MBeanUtil.invoke(MBeanUtil.java:105)
at
com.sun.enterprise.tools.admingui.util.MBeanUtil.invoke(MBeanUtil.java:35)
at
com.sun.enterprise.tools.admingui.util.MBeanUtil.invokeMBean(MBeanUtil.java:140)
at
com.sun.enterprise.tools.admingui.handlers.CommonHandlers.invokeMBean(CommonHandlers.java:83)
at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
com.sun.enterprise.tools.guiframework.view.DescriptorViewHelper.invokeHandler(DescriptorViewHelper.java:785)
at
com.sun.enterprise.tools.guiframework.view.DescriptorViewHelper.dispatchEvent(DescriptorViewHelper.java:731)
at
com.sun.enterprise.tools.guiframework.view.DescriptorViewHelper.execute(DescriptorViewHelper.java:250)
at
com.sun.enterprise.tools.guiframework.view.DescriptorViewBeanBase.execute(DescriptorViewBeanBase.java:187)
at
Re: Sun 8.0.1 Appserver pooling
myrnap wrote: Nat Gross wrote: Hi; Although I have no problems connecting to my new Derby, via jdbc, I cannot get a 'ping' when setting up a j2ee pool and jndi connector in the Sun app server. I followed the instructions on the java.net blog,for embedded, the classpath is set, have tried various javax connectors, the xa version and non xa version, to no avail. Your help will be appreciated. Thanks -nat Nat, What's the error you see? What's in the server.log? Does a derby.log get created? If so, is it where you expect it to be? Myrna Progress For some reason the sdk's bin directory wasn't in the PATH. I didn't dream that the gui admin uses the cmdline stuff behind the scenes. Anyhow, now there is a new error when pinging. The first exception sais that it couldn't open the database and the next exception has the details why. But the next exception list some gui framework error, for the ping button. Here it is.: Log Level: INFO Logger: javax.enterprise.system.tools.admin Name-Value Pairs: _ThreadID=12; Record Number: 6149 Message ID: com.sun.enterprise.tools.guiframework.exception.FrameworkError Complete Message com.sun.enterprise.tools.guiframework.exception.FrameworkException: java.lang.reflect.InvocationTargetException on 'class com.sun.enterprise.tools.admingui.handlers.CommonHandlers.invokeMBean'. This occurred while attempting to process a 'command' event for 'pingButton'. at com.sun.enterprise.tools.guiframework.view.DescriptorViewHelper.execute(DescriptorViewHelper.java:279) at com.sun.enterprise.tools.guiframework.view.DescriptorViewBeanBase.execute(DescriptorViewBeanBase.java:187) at com.iplanet.jato.view.RequestHandlingViewBase.handleRequest(RequestHandlingViewBase.java:308) at com.iplanet.jato.view.ViewBeanBase.dispatchInvocation(ViewBeanBase.java:822) at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandlerInternal(ViewBeanBase.java:760) at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandlerInternal(ViewBeanBase.java:780) at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandler(ViewBeanBase.java:590) at com.iplanet.jato.ApplicationServletBase.dispatchRequest(ApplicationServletBase.java:951) at com.iplanet.jato.ApplicationServletBase.processRequest(ApplicationServletBase.java:622) at com.sun.enterprise.tools.guiframework.view.BaseServlet.processRequest(BaseServlet.java:186) at com.iplanet.jato.ApplicationServletBase.doPost(ApplicationServletBase.java:480) at com.sun.enterprise.tools.admingui.AdminGUIServlet.doPost(AdminGUIServlet.java:65) at javax.servlet.http.HttpServlet.service(HttpServlet.java:768) at javax.servlet.http.HttpServlet.service(HttpServlet.java:861) at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:246) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:500) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:268) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:236) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:141) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:214) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:168) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:536) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:144) at
Re: Sun 8.0.1 Appserver pooling
Nat Gross wrote:
myrnap wrote:
Nat Gross wrote:
Hi;
Although I have no problems connecting to my new Derby, via jdbc, I
cannot get a 'ping' when setting up a j2ee pool and jndi connector
in the Sun app server. I followed the instructions on the java.net
blog,for embedded, the classpath is set, have tried various javax
connectors, the xa version and non xa version, to no avail.
Your help will be appreciated.
Thanks
-nat
Nat,
What's the error you see?
What's in the server.log?
Does a derby.log get created? If so, is it where you expect it to be?
Myrna
Progress For some reason the sdk's bin directory wasn't in the
PATH. I didn't dream that the gui admin uses the cmdline stuff behind
the scenes. Anyhow, now there is a new error when pinging.
The first exception sais that it couldn't open the database and the
next exception has the details why. But the next exception list some
gui framework error, for the ping button. Here it is.:
Hm, I like the classnot found problem more - at least then we know it's
the classpath, somehow. :-)
I would've checked whether derby.jar was in the lib, or lib/ext dir...
The 'Failed to start database ...' error can be caused by a number of
situations...Unfortunately, I think the app server gobbles up the nested
(i.e. 'next') exception...
Perhaps someone else knows more about the framework error...
The situation I'm thinking you might be hitting is somehow 2
jvms/processes trying to get hold of the same database.
In that case, you would see a derby.log that looks completely fine and
healthy (because of the first jvm starting the database), but still get
this error. And of course, you'd see an extra (java or javaw) process
after the ping.
To see more, I suggest you add the following derby.properties file to
the derby.system.home dir (practically speaking, that would be where
derby.log gets created.):
derby.infolog.append=true
derby.language.logStatementText=true
derby.stream.error.logSeverityLevel=0
If it is the multiple jvm situation, then you will see a neat starting
message in derby.log still get this error. If it's something else,
then possibly the database does not get opened at all, and your
derby.log would be an empty file even after infolog.append is picked up
from derby.properties.
Now, why there would be 2 jvms trying to start the database - I don't
know...Does the ping start a second process/jvm?
Another area to look at is the policy files. This is really a wild
guessBut make sure the following permissions are set for the derby
database:
grant codeBase file://your domain/lib dir/derby.jar {
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission derby.*, read;
permission java.io.FilePermission ${derby.system.home}${/} -,
read,write,delete;
I hope this helps any
Myrna
Sun 8.0.1 Appserver pooling
Hi; Although I have no problems connecting to my new Derby, via jdbc, I cannot get a 'ping' when setting up a j2ee pool and jndi connector in the Sun app server. I followed the instructions on the java.net blog,for embedded, the classpath is set, have tried various javax connectors, the xa version and non xa version, to no avail. Your help will be appreciated. Thanks -nat
Re: Sun 8.0.1 Appserver pooling
Nat Gross wrote: Hi; Although I have no problems connecting to my new Derby, via jdbc, I cannot get a 'ping' when setting up a j2ee pool and jndi connector in the Sun app server. I followed the instructions on the java.net blog,for embedded, the classpath is set, have tried various javax connectors, the xa version and non xa version, to no avail. Your help will be appreciated. Thanks -nat Nat, What's the error you see? What's in the server.log? Does a derby.log get created? If so, is it where you expect it to be? Myrna
