RE: MS SQL Server/JTDS Driver DB Connectivity
Scott, The J2 pool appears to be managed by commons dbcp, configured by JNDI resources in jetspeed.xml. The OJB is configured to use the JNDI connection source in etc/db-obj/repository_database.xml. I am not sure if the OJB configuration attempts to pool the connections again or not. In etc/db-obj/OJB.properties, it enables a pooled connection manager. In addition, etc/db-obj/repository_database.xml also contains a connection pool definition, (it even has an unused validationQuery attribute). I think OJB should be configured to not pool and let the JNDI connection source do it. No need to double pool! Plus, execution of the validationQuery is bad enoough... I do not think it would be efficient to have both pools executing validation queries! Got to figure this stuff out... perhaps DLS could shed some light here? Randy -Original Message- From: Scott T. Weaver To: Randy Watler Sent: 10/22/04 7:45 AM Subject: Re: MS SQL Server/JTDS Driver DB Connectivity Let me check and see if anyone has had these issuses. How is the pool managed? Randy Watler wrote: Scott, I have been reasearching DB connectivity issues we have seen on our production box. The problem is rare, but occasionally the DB simply resets a connection in the pool. The JTDS driver I think we are both using does not seem to have any way to specify autoReconnect, (something that other drivers allow). From what I have gathered today, many seem to use a validationQuery that is run before a connection is handed to the application from the connection pool. For instance, this validation query could be defined in jetspeed.xml for the JNDI connection pool resource configuration: SELECT GETDATE(). Personally, I think this is overkill when a simple retry try/catch could be implemented in the driver, but JTDS's opinion is that it is not their problem. This issue seems to come up only with MS SQL Server and certain drivers, so I was wondering what you were doing, (or planned to do), in your production environment. Thanks in advance for any tips you can provide... Randy
Re: MS SQL Server/JTDS Driver DB Connectivity
Randy Watler wrote: Scott, The J2 pool appears to be managed by commons dbcp, configured by JNDI resources in jetspeed.xml. The OJB is configured to use the JNDI connection source in etc/db-obj/repository_database.xml. I am not sure if the OJB configuration attempts to pool the connections again or not. In etc/db-obj/OJB.properties, it enables a pooled connection manager. In addition, etc/db-obj/repository_database.xml also contains a connection pool definition, (it even has an unused validationQuery attribute). I don't think OJB tries to pool JNDI datasources. I am not 100% on that though. I think OJB should be configured to not pool and let the JNDI connection source do it. No need to double pool! Plus, execution of the validationQuery is bad enoough... I do not think it would be efficient to have both pools executing validation queries! Is OJB doing the validation queries? If so, I think that feature can be disabled in OJB.properties. Got to figure this stuff out... perhaps DLS could shed some light here? Randy -Original Message- From: Scott T. Weaver To: Randy Watler Sent: 10/22/04 7:45 AM Subject: Re: MS SQL Server/JTDS Driver DB Connectivity Let me check and see if anyone has had these issuses. How is the pool managed? Randy Watler wrote: Scott, I have been reasearching DB connectivity issues we have seen on our production box. The problem is rare, but occasionally the DB simply resets a connection in the pool. The JTDS driver I think we are both using does not seem to have any way to specify autoReconnect, (something that other drivers allow). From what I have gathered today, many seem to use a validationQuery that is run before a connection is handed to the application from the connection pool. For instance, this validation query could be defined in jetspeed.xml for the JNDI connection pool resource configuration: SELECT GETDATE(). Personally, I think this is overkill when a simple retry try/catch could be implemented in the driver, but JTDS's opinion is that it is not their problem. This issue seems to come up only with MS SQL Server and certain drivers, so I was wondering what you were doing, (or planned to do), in your production environment. Thanks in advance for any tips you can provide... Randy -- Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Admiral Hyman Rickover *** * Scott T. Weaver * * [EMAIL PROTECTED] * * http://www.einnovation.com* * -- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEdit, Website Content Management * * http://www.openedit.org * *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MS SQL Server/JTDS Driver DB Connectivity
Scott, I am not sure what is actually functional. I aim to figure that out. OJB is not configured with a valid validationQuery, it just has an empty attribute placeholder in repository_database.xml. The reason I am digging around in here is that there is a fairly good chance that I'll need to add a validation query. I am not a big fan of using it in principle, but if your reasearch shows that it is needed for MS SQL Server, that will just about make it unanimous... :(. So, I want to enable it in the right place. Also, if we do put them at the JNDI level, OJB cannot pool: obviously, it would defeat the purpose of using a validationQuery if it did not issue the validationQuery again! Randy -Original Message- From: Scott T. Weaver To: Jetspeed Developers List Sent: 10/22/04 8:49 AM Subject: Re: MS SQL Server/JTDS Driver DB Connectivity Randy Watler wrote: Scott, The J2 pool appears to be managed by commons dbcp, configured by JNDI resources in jetspeed.xml. The OJB is configured to use the JNDI connection source in etc/db-obj/repository_database.xml. I am not sure if the OJB configuration attempts to pool the connections again or not. In etc/db-obj/OJB.properties, it enables a pooled connection manager. In addition, etc/db-obj/repository_database.xml also contains a connection pool definition, (it even has an unused validationQuery attribute). I don't think OJB tries to pool JNDI datasources. I am not 100% on that though. I think OJB should be configured to not pool and let the JNDI connection source do it. No need to double pool! Plus, execution of the validationQuery is bad enoough... I do not think it would be efficient to have both pools executing validation queries! Is OJB doing the validation queries? If so, I think that feature can be disabled in OJB.properties. Got to figure this stuff out... perhaps DLS could shed some light here? Randy -Original Message- From: Scott T. Weaver To: Randy Watler Sent: 10/22/04 7:45 AM Subject: Re: MS SQL Server/JTDS Driver DB Connectivity Let me check and see if anyone has had these issuses. How is the pool managed? Randy Watler wrote: Scott, I have been reasearching DB connectivity issues we have seen on our production box. The problem is rare, but occasionally the DB simply resets a connection in the pool. The JTDS driver I think we are both using does not seem to have any way to specify autoReconnect, (something that other drivers allow). From what I have gathered today, many seem to use a validationQuery that is run before a connection is handed to the application from the connection pool. For instance, this validation query could be defined in jetspeed.xml for the JNDI connection pool resource configuration: SELECT GETDATE(). Personally, I think this is overkill when a simple retry try/catch could be implemented in the driver, but JTDS's opinion is that it is not their problem. This issue seems to come up only with MS SQL Server and certain drivers, so I was wondering what you were doing, (or planned to do), in your production environment. Thanks in advance for any tips you can provide... Randy -- Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Admiral Hyman Rickover *** * Scott T. Weaver * * [EMAIL PROTECTED] * * http://www.einnovation.com* * -- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEdit, Website Content Management * * http://www.openedit.org * *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
