[dbcp] Status of Bug 35591
Hi, I just wondered what the status of the following bug is: http://issues.apache.org/bugzilla/show_bug.cgi?id=35591 Basically this bug prevents one to create serializable connections with connection checking and without auto commit for any oracle database. The problem is that setting the transaction isolation after the validation query does not work for oracle because the transaction isolation has to be set before any query is issued to the database. I believe I have analyzed the problem correctly; there is a testcase which shows the problem, I believe I have provided a reasonable patch, but I did never hear anything about it; at least there are no comments or anything added in bugzilla. The problem has appeared at the db-torque project (http://db.apache.org/torque/) and it would be nice to know whether the problem will be solved. If you disagree with the solution or there is a problem with the provided patch, please let me know. If another solution is preferred I'd volunteer to implement it; just give some hint about the direction to go. I appreciate that the problem is quite complex and the solution digs deep into the internals of dbcp, so it is clear that it takes some time looking at it. I just wanted to brush the dust off it. Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jdbc2pool [was Re: DBCP status?]
Hello John! I do think I see certain (serious) issues with the code, and I have started to compose a comprehensive mail on this, but let us please first discuss the [dbcp] Do we need Referenceable? thread I'm starting now as the outcome of the discussion will influence greatly what my advice on improving jdbc2 will be. Okay? Please expect my detailed answer to your mail in several days, a week at most. - Anton AT Have looked a couple of weeks ago AT * jdbc2 part seemed out of operation to me (just can't go into a release) JM I've seen a couple statements like this. No one presents any reasons JM for their statement though. I started this pool and use it in JM production, so have dual interest in hearing what the problems are. I JM see one bug entered against it, but I would not classify it as a JM blocker. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jdbc2pool [was Re: DBCP status?]
Have looked a couple of weeks ago * jdbc2 part seemed out of operation to me (just can't go into a release) I've seen a couple statements like this. No one presents any reasons for their statement though. I started this pool and use it in production, so have dual interest in hearing what the problems are. I see one bug entered against it, but I would not classify it as a blocker. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
--- Serge Knystautas [EMAIL PROTECTED] wrote: David Graham wrote: This entire thread has been filled with reasons to not support closing abandoned connections. If you need to have this behavior, you will need to customize DBCP for your apps because it should not be built in. However, any app that needs a connection pool to clean up after it is highly suspect. Err... that's a bit of a blanket statement, and IMHO requiring an ideal world that I no longer am apart of. Most of my work these days is being the (Java/app) guru coming in pointing all the problems that are making the app server crash daily. (too much writing word docs and not enough code for my tastes, but kids to feed...) For one client, an errant search query can throttling Oracle because it hits some combination of terms that prompts a table scan. For another, I think the firewall that is dropping the close-tcp signal so the JVM thinks the connection is still waiting for something to happen. And on and on. I'm stuck dealing with lots of extremely suspect code. I know how you feel. DBCP won't save you in these cases; training people in the simple ways of cleaning up resources properly will. I think a lot of people downloading Tomcat and others will have similar issues with errant connections. I think this need is also what prompted the original attempt at abandoned connection recovery. As to how this thread has all these reasons to not close these kind of connections... I'm sorry, but I've followed every post and have missed them. I've seen (and argued) why you shouldn't try to return a connection in this state to the pool. There were also some issues with how it was not coded well in the first place and created unnecessarily complexity. If someone could quickly state a few reasons, I would be most appreciative. It is not the pool's responsibility to clean up after poorly coded apps. There is a clear separation of concerns between the pool and the app. The pool maintains the connections, the app properly uses the API and returns all connections when finished with them. There is no sound algorithm for determining when a connection is abandoned because DBCP doesn't have all the information required to make that decision. There are more but I've stated them previously. Many Jakarta projects use commons-logging to separate themselves from any particular logging implementation. Implementing listeners is over engineering what should be a simple solution. I believe commons-pool, on which DBCP is based, supports listeners for various events. Dude, sorry... someone had balked on the listserv about adding commons-logging as a dependency, so this was another idea. If we can hook into commons-pool's listeners, then we can use that engineering for For some reason there are people against adding commons-logging to DBCP. I don't know of any good reason not to. David free. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
--- Juozas Baliuka [EMAIL PROTECTED] wrote: I see it was a very big mistake to add AbandonedObjectPool, it was added for debugging but people misunderstanding it. I think we need to deprecate or remove it. It's already deprecated. David - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 7:43 AM Subject: RE: DBCP status? This entire thread has been filled with reasons to not support closing abandoned connections. If you need to have this behavior, you will need to customize DBCP for your apps because it should not be built in. Actually, I would characterize it that abandoned connection handling is an FAQ item *and* a polarizing one. Yes, there have been reasons to not support closing abandoned connections. And just as loudly have been people saying that they need it. Personally, I am still in a listening mode (plus I've been head down working on a new server deployment). I've some thoughts, but I also knew that Serge was off-line for a bit (and had a bunch of changes already on his local drive), so I was waiting for him to return, too. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Juozas Baliuka wrote: I see it was a very big mistake to add AbandonedObjectPool, it was added for debugging but people misunderstanding it. I think we need to deprecate or remove it. +1 was it part of the 1.0 release?? martin - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 7:43 AM Subject: RE: DBCP status? This entire thread has been filled with reasons to not support closing abandoned connections. If you need to have this behavior, you will need to customize DBCP for your apps because it should not be built in. Actually, I would characterize it that abandoned connection handling is an FAQ item *and* a polarizing one. Yes, there have been reasons to not support closing abandoned connections. And just as loudly have been people saying that they need it. Personally, I am still in a listening mode (plus I've been head down working on a new server deployment). I've some thoughts, but I also knew that Serge was off-line for a bit (and had a bunch of changes already on his local drive), so I was waiting for him to return, too. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
It appears clear that there are two camps, each with fairly strong views. Personally, I believe that both camps can be accomodated in a way that should satisfy both. DBCP should focus on core pooling behavior related to connections and prepared statements, and leave policy issues to specialized subclasses. If DBCP is clean, without any reclaiming of connections and properly setup to be subclassed, including subclassing a delegating connection, then whomever needs a specialized connection pool that reclaims connections based upon some policy can do so. DelegatingConnection, and the rest of the core objects should be pure and focused only on the necessary behavior to implement connection pooling. DBCP should focus on what has to happen when a connection is requested or returned. Behavior, not policy, should be the watch word. There is enough behavior to deal with related to connection pooling, including ensuring the proper state of pooled connections. Some of the AbandonedTrace behavior is still necessary to implement the JDBC specification. Connections still need to track outstanding statements and results sets, which are closed by Connection.close(). However, the abandoned semantic is not in the specification. It is perfectly permissible to leave a ResultSet or Statement open, and expect the connection to close it. Nor is it necessary for DBCP to track leaks, regardless of whether or not it is implementing recovery. Both of that behavior can be implemented by specialized subclasses. DBCP may wish to provide abstract classes that facilitate specialization. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
--- Noel J. Bergman [EMAIL PROTECTED] wrote: It appears clear that there are two camps, each with fairly strong views. Personally, I believe that both camps can be accomodated in a way that should satisfy both. DBCP should focus on core pooling behavior related to connections and prepared statements, and leave policy issues to specialized subclasses. If DBCP is clean, without any reclaiming of connections and properly setup to be subclassed, including subclassing a delegating connection, then whomever needs a specialized connection pool that reclaims connections based upon some policy can do so. DelegatingConnection, and the rest of the core objects should be pure and focused only on the necessary behavior to implement connection pooling. DBCP should focus on what has to happen when a connection is requested or returned. Behavior, not policy, should be the watch word. There is enough behavior to deal with related to connection pooling, including ensuring the proper state of pooled connections. Some of the AbandonedTrace behavior is still necessary to implement the JDBC specification. Connections still need to track outstanding statements and results sets, which are closed by Connection.close(). Agreed, but the way it was implemented was completely wrong. The behavior should not have been in a superclass and forced unrelated classes to subclass it. However, the abandoned semantic is not in the specification. It is perfectly permissible to leave a ResultSet or Statement open, and expect the connection to close it. Nor is it necessary for DBCP to track leaks, regardless of whether or not it is implementing recovery. Both of that behavior can be implemented by specialized subclasses. I agree. Let DBCP focus on it's core responsibilities and provide easy hooks to allow logging, policy decisions, etc. David DBCP may wish to provide abstract classes that facilitate specialization. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
Some of the AbandonedTrace behavior is still necessary to implement the JDBC specification. Connections still need to track outstanding statements and results sets, which are closed by Connection.close(). Agreed, but the way it was implemented was completely wrong. The behavior should not have been in a superclass and forced unrelated classes to subclass it. I actually had a sentence about that, but I removed it. Let DBCP focus on it's core responsibilities and provide easy hooks to allow logging, policy decisions, etc. What hooks do you see as necessary in the base class(es)? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
David Graham wrote: I know how you feel. DBCP won't save you in these cases; training people in the simple ways of cleaning up resources properly will. Yeah, I have plans on how to spot these issues better ahead of time. Also, just starting to use p6spy as my magic bullet in the short-term... It is not the pool's responsibility to clean up after poorly coded apps. There is a clear separation of concerns between the pool and the app. The pool maintains the connections, the app properly uses the API and returns all connections when finished with them. There is no sound algorithm for determining when a connection is abandoned because DBCP doesn't have all the information required to make that decision. There are more but I've stated them previously. I disagree about the lack of a sound algorithm, but I have come to agree about this not being the pool's responsibility. So I agree the pooler should just try to avoid opening connections each time (general pool issues), and not get into these application issues. For some reason there are people against adding commons-logging to DBCP. I don't know of any good reason not to. I think it's just because it's to keep the dependency tree thin. I haven't been burned yet, but in some of my apps I have dependencies on common libs from 5 higher level apps. I think eventually I'll get burned by 2 different apps requiring 2 different versions of commons-beanutils (just to pick one). -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
On Wed, 2 Jul 2003, Serge Knystautas wrote: [snip] For some reason there are people against adding commons-logging to DBCP. I don't know of any good reason not to. I think it's just because it's to keep the dependency tree thin. I haven't been burned yet, but in some of my apps I have dependencies on common libs from 5 higher level apps. I think eventually I'll get burned by 2 different apps requiring 2 different versions of commons-beanutils (just to pick one). There's a couple of interesting notes about this to consider: * If you are using other commons packages already, you're very likely already committed to having commons-logging available, as it is quite widely used. According to Gump's cross reference charts, this seems to be true for lots of other code as well (the itch that C-L scratches appears to have been fairly common). * If you don't use C-L, then you're either going to mandate some specific logging solution, or go without the benefits of logging in DBCP. Neither of those choices seems like a particularly good idea for a general purpose component. * If you really do need two different versions of something like commons-beanutils, and the two versions are incompatible with each other, then we've failed at a primary mission of commons. In the particular case of beanutils, I know for a fact that code needing only the APIs that were there in 1.0 will still work with 1.6.1, as I've lived through all of them (dependence on particular bugs, of course, is another story :-). But this is why Commons developers tend to be *very* conservative about API changes that are not backwards compatible. Serge Knystautas Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
On Thu, 3 Jul 2003 10:10 am, Craig R. McClanahan wrote: * If you don't use C-L, then you're either going to mandate some specific logging solution, or go without the benefits of logging in DBCP. Neither of those choices seems like a particularly good idea for a general purpose component. You could always just add a listener architecture (as commons-pool already has) and let anyone tie in arbitrary logging systems. It also has the advantage that you don't have to worry about i18n as the implementation of the listener does the i18n rather than the component that pushes it out to the logger directly. -- Cheers, Peter Donald *---* | A handful of sand is an anthology of the | |universe. -Albert Einstein| *---* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
--- Noel J. Bergman [EMAIL PROTECTED] wrote: Some of the AbandonedTrace behavior is still necessary to implement the JDBC specification. Connections still need to track outstanding statements and results sets, which are closed by Connection.close(). Agreed, but the way it was implemented was completely wrong. The behavior should not have been in a superclass and forced unrelated classes to subclass it. I actually had a sentence about that, but I removed it. Let DBCP focus on it's core responsibilities and provide easy hooks to allow logging, policy decisions, etc. What hooks do you see as necessary in the base class(es)? Listener and Strategy architectures are really useful for implementing hooks that don't require subclassing. I really think DBCP should use commons-logging but if the majority believes otherwise, I'll make that compromise. For other features we may be able to leverage the notifications that commons-pool already sends out and translate them into DBCP events. I'd like to see the next release of DBCP squash the open bugs and then we can remove the deprecated Abandoned* classes and start on some new ideas. If they're significantly different than the current DBCP, we can increment the major release number to 2.0 and break backwards compatibility to move forward. David --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: DBCP status?
Hello Serge! Serge Knystautas wrote: SK I agree trying to recover connections is bad. I've found it leads to SK problems that don't show up during a test phase become very confusing SK and challenging problems in production once under high-load. SK The approach I took was this SK a) support an optional max-active time threshold, which means there is a SK time limit to how long a connection can be marked as in use. SK b) if this threshold is exceeded, you close the connection. The value SK of trying to return it to the pool is minimal, while the downside of SK returning a mid-transaction/statement connection to a pool is very bad SK and nearly impossible to track down. Yes, the connection shouldn't be put back to pool. Yes, we should log this as an error. Yes, the Throwable from section c) will greately help. If the pool is to provide any feedback statistics probably we should report separately three values: * # of active connections * # of idle connections * # of over-timed connections Now, two questions of the year: b1) to close this connection or not to close? b2) if maxActive 0 should this connection no longer be counted as active for the purpose of enforcing the policies of WHEN_EXHAUSTED_FAIL WHEN_EXHAUSTED_BLOCK ? I guess we have to choose from the following matrix of alternatives b1 b2 1 1 0 0 0 1 Thoughts? SK c) support an optional debug step that will create a Throwable when SK getConnection is called. Then if the max-active threshold is hit, we SK can print the stack trace of where the aged connection was grabbed, and SK in development/testing, quickly resolve the errant connection. This is a separate idea on its own and a very good one I think :-) The message logging a connection that has been borrowed from the pool too long will greatly benefit from this stack trace. - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
--- Serge Knystautas [EMAIL PROTECTED] wrote: David Graham wrote: The problem was that DBCP was trying to track and recover abandoned connections. This isn't just an implementation problem, it's a philosophy problem. Pool semantics dictate that client applications behave properly when checking out and returning pool resources. The pool is absolutely not responsible for fixing poorly behaving applications. This led to bugs, questions, convoluted inheritance hierachies/code, and promoted the idea that users didn't have to bother writing their applications properly because the pool would fix their apps for them. The pool should keep track of how long a connection has been checked out and log a message when it passes some configurable threshold but it should never try to grab the connection back from the application. I agree trying to recover connections is bad. I've found it leads to problems that don't show up during a test phase become very confusing and challenging problems in production once under high-load. The approach I took was this a) support an optional max-active time threshold, which means there is a time limit to how long a connection can be marked as in use. There is a maxActive property of BasicDataSource that defines the maximum number of open connections. Adding a time limit is reasonable if step b is changed below. b) if this threshold is exceeded, you close the connection. The value of trying to return it to the pool is minimal, while the downside of returning a mid-transaction/statement connection to a pool is very bad and nearly impossible to track down. DBCP should not close connections that have been borrowed from the pool. It should only log a possible error when the configured time limit has been exceeded. c) support an optional debug step that will create a Throwable when getConnection is called. Then if the max-active threshold is hit, we can print the stack trace of where the aged connection was grabbed, and in development/testing, quickly resolve the errant connection. I'm ok with this as long the stack trace isn't logged like an exception. It will be confusing for people to see a stack trace that isn't really associated with an exception so the message should indicate that it's identifying a possible connection leak location. David Does this seem reasonable? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
b) if this threshold is exceeded, you close the connection. The value of trying to return it to the pool is minimal, while the downside of returning a mid-transaction/statement connection to a pool is very bad and nearly impossible to track down. DBCP should not close connections that have been borrowed from the pool. It should only log a possible error when the configured time limit has been exceeded. c) support an optional debug step that will create a Throwable when getConnection is called. Then if the max-active threshold is hit, we can print the stack trace of where the aged connection was grabbed, and in development/testing, quickly resolve the errant connection. I'm ok with this as long the stack trace isn't logged like an exception. It will be confusing for people to see a stack trace that isn't really associated with an exception so the message should indicate that it's identifying a possible connection leak location. I log message if the active-connections = max-connections, it helps to configure pools (increase max-connections or decrease max-threads). finally close is not any kind of problem, it is in single place per application, if resource management is well designed. It can be usefull for crapy applications only, I do not think we need some kind of special support for crap in commons. David Does this seem reasonable? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: DBCP status?
Hello David! DG DBCP should not close connections that have been borrowed from the pool. DG It should only log a possible error when the configured time limit has DG been exceeded. What do you think, should this overtimed connection still be considered active for the purpose of enforsing WHEN_EXHAUSTED_FAIL or WHEN_EXHAUSTED_BLOCK? Should the active connection counter rather be decreased by 1 once a connection overtimes? SK c) support an optional debug step that will create a Throwable when SK getConnection is called. Then if the max-active threshold is hit, we SK can print the stack trace of where the aged connection was grabbed, and SK in development/testing, quickly resolve the errant connection. DG I'm ok with this as long the stack trace isn't logged like an exception. DG It will be confusing for people to see a stack trace that isn't really DG associated with an exception so the message should indicate that it's DG identifying a possible connection leak location. We can envent some special exception, something like ConnectionOvertimeDetected or smth better, but give it such a descriptive name and message that would save the user from confusion. Or we could create a cascading exception that would have a getCause() method that would return the original exception as the root cause (it is in some sense a root cause) - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: DBCP status?
--- Anton Tagunov [EMAIL PROTECTED] wrote: Hello David! DG DBCP should not close connections that have been borrowed from the pool. DG It should only log a possible error when the configured time limit has DG been exceeded. What do you think, should this overtimed connection still be considered active for the purpose of enforsing WHEN_EXHAUSTED_FAIL or WHEN_EXHAUSTED_BLOCK? Connections that have been checked out of the pool should always be counted in the WHEN_EXHAUSTED_FAIL check regardless of the amount of time they've been checked out. David Should the active connection counter rather be decreased by 1 once a connection overtimes? SK c) support an optional debug step that will create a Throwable when SK getConnection is called. Then if the max-active threshold is hit, we SK can print the stack trace of where the aged connection was grabbed, and SK in development/testing, quickly resolve the errant connection. DG I'm ok with this as long the stack trace isn't logged like an exception. DG It will be confusing for people to see a stack trace that isn't really DG associated with an exception so the message should indicate that it's DG identifying a possible connection leak location. We can envent some special exception, something like ConnectionOvertimeDetected or smth better, but give it such a descriptive name and message that would save the user from confusion. Or we could create a cascading exception that would have a getCause() method that would return the original exception as the root cause (it is in some sense a root cause) - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re[2]: DBCP status?
Entering in the middle here... I added a logging statement in my pool that reports overdue connections and it's been helpful in alerting us to problems. One thing to consider is adding a hook that allows you to borrow a connection without generating these errors if you know that you'll be using the connection for a long time. For example, I have some background jobs that run and might use a connection for upwards of 30 minutes or more. These shouldn't be grouped in with the same requests to my web app which should only need a connection for a few seconds at most. Perhaps too specialized of a requirement, but it works for me ;) Also, I went as far as wrapping the Connection object returned from the DriverManager in my own so it could keep track of Statements that it created to ensure that they get closed. When the borrowed connection is returned to the pool it will log any open statements and the corresponding stacktrace for their creation and this has eliminated any statements being left open. This type of overhead is only necessary to weed out any mistakes early on and should be turned off for production code. - Mark -Original Message- From: Anton Tagunov [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:40 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re[2]: DBCP status? Hello David! DG DBCP should not close connections that have been borrowed from the pool. DG It should only log a possible error when the configured time limit has DG been exceeded. What do you think, should this overtimed connection still be considered active for the purpose of enforsing WHEN_EXHAUSTED_FAIL or WHEN_EXHAUSTED_BLOCK? Should the active connection counter rather be decreased by 1 once a connection overtimes? SK c) support an optional debug step that will create a Throwable when SK getConnection is called. Then if the max-active threshold is hit, we SK can print the stack trace of where the aged connection was grabbed, and SK in development/testing, quickly resolve the errant connection. DG I'm ok with this as long the stack trace isn't logged like an exception. DG It will be confusing for people to see a stack trace that isn't really DG associated with an exception so the message should indicate that it's DG identifying a possible connection leak location. We can envent some special exception, something like ConnectionOvertimeDetected or smth better, but give it such a descriptive name and message that would save the user from confusion. Or we could create a cascading exception that would have a getCause() method that would return the original exception as the root cause (it is in some sense a root cause) - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re[2]: DBCP status?
--- Ford, Mark [EMAIL PROTECTED] wrote: Entering in the middle here... I added a logging statement in my pool that reports overdue connections and it's been helpful in alerting us to problems. One thing to consider is adding a hook that allows you to borrow a connection without generating these errors if you know that you'll be using the connection for a long time. For example, I have some background jobs that run and might use a connection for upwards of 30 minutes or more. These shouldn't be grouped in with the same requests to my web app which should only need a connection for a few seconds at most. Perhaps too specialized of a requirement, but it works for me ;) This is exactly why DBCP should never grab connections back from an app. It doesn't have enough information to make that decision. Also, I went as far as wrapping the Connection object returned from the DriverManager in my own so it could keep track of Statements that it created to ensure that they get closed. When the borrowed connection is returned to the pool it will log any open statements and the corresponding stacktrace for their creation and this has eliminated any statements being left open. This type of overhead is only necessary to weed out any mistakes early on and should be turned off for production code. This is fine for your app but shouldn't be added to DBCP directly. DBCP might provide hooks where you could plugin this behavior but resource cleanup is the app's responsibility. David - Mark -Original Message- From: Anton Tagunov [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:40 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re[2]: DBCP status? Hello David! DG DBCP should not close connections that have been borrowed from the pool. DG It should only log a possible error when the configured time limit has DG been exceeded. What do you think, should this overtimed connection still be considered active for the purpose of enforsing WHEN_EXHAUSTED_FAIL or WHEN_EXHAUSTED_BLOCK? Should the active connection counter rather be decreased by 1 once a connection overtimes? SK c) support an optional debug step that will create a Throwable when SK getConnection is called. Then if the max-active threshold is hit, we SK can print the stack trace of where the aged connection was grabbed, and SK in development/testing, quickly resolve the errant connection. DG I'm ok with this as long the stack trace isn't logged like an exception. DG It will be confusing for people to see a stack trace that isn't really DG associated with an exception so the message should indicate that it's DG identifying a possible connection leak location. We can envent some special exception, something like ConnectionOvertimeDetected or smth better, but give it such a descriptive name and message that would save the user from confusion. Or we could create a cascading exception that would have a getCause() method that would return the original exception as the root cause (it is in some sense a root cause) - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: DBCP status?
It is nothing bad to add some logging to pool, but no workarounds. Application must work with any pool implementation and not to depend on workarounds in pool. But I see nothing bad if application uses resource manager (It is not a pool) and *never* closes connections, connection returned from this kind of manager must throw Exception on close. It is very bad thing to break contracts in stable componnents, just for some crapy application support. Read arhives, it was discussed a lot of times in [dbcp]. - Original Message - From: Ford, Mark [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 5:07 PM Subject: RE: Re[2]: DBCP status? Entering in the middle here... I added a logging statement in my pool that reports overdue connections and it's been helpful in alerting us to problems. One thing to consider is adding a hook that allows you to borrow a connection without generating these errors if you know that you'll be using the connection for a long time. For example, I have some background jobs that run and might use a connection for upwards of 30 minutes or more. These shouldn't be grouped in with the same requests to my web app which should only need a connection for a few seconds at most. Perhaps too specialized of a requirement, but it works for me ;) Also, I went as far as wrapping the Connection object returned from the DriverManager in my own so it could keep track of Statements that it created to ensure that they get closed. When the borrowed connection is returned to the pool it will log any open statements and the corresponding stacktrace for their creation and this has eliminated any statements being left open. This type of overhead is only necessary to weed out any mistakes early on and should be turned off for production code. - Mark -Original Message- From: Anton Tagunov [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:40 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re[2]: DBCP status? Hello David! DG DBCP should not close connections that have been borrowed from the pool. DG It should only log a possible error when the configured time limit has DG been exceeded. What do you think, should this overtimed connection still be considered active for the purpose of enforsing WHEN_EXHAUSTED_FAIL or WHEN_EXHAUSTED_BLOCK? Should the active connection counter rather be decreased by 1 once a connection overtimes? SK c) support an optional debug step that will create a Throwable when SK getConnection is called. Then if the max-active threshold is hit, we SK can print the stack trace of where the aged connection was grabbed, and SK in development/testing, quickly resolve the errant connection. DG I'm ok with this as long the stack trace isn't logged like an exception. DG It will be confusing for people to see a stack trace that isn't really DG associated with an exception so the message should indicate that it's DG identifying a possible connection leak location. We can envent some special exception, something like ConnectionOvertimeDetected or smth better, but give it such a descriptive name and message that would save the user from confusion. Or we could create a cascading exception that would have a getCause() method that would return the original exception as the root cause (it is in some sense a root cause) - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.491 / Virus Database: 290 - Release Date: 2003.06.23 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
David Graham wrote: The approach I took was this a) support an optional max-active time threshold, which means there is a time limit to how long a connection can be marked as in use. There is a maxActive property of BasicDataSource that defines the maximum number of open connections. Adding a time limit is reasonable if step b is changed below. b) if this threshold is exceeded, you close the connection. The value of trying to return it to the pool is minimal, while the downside of returning a mid-transaction/statement connection to a pool is very bad and nearly impossible to track down. DBCP should not close connections that have been borrowed from the pool. It should only log a possible error when the configured time limit has been exceeded. I *need* the pooler to close connections that have been borrowed from the pool and forgotten to be closed. Can you give a) reasons why not to close them because of an optional parameter and b) suggested workaround? I'm ok with this as long the stack trace isn't logged like an exception. It will be confusing for people to see a stack trace that isn't really associated with an exception so the message should indicate that it's identifying a possible connection leak location. I think there's a relunctance (including mine) to create a dependency on commons-logging (or another logger), so I was thinking about a PoolListener service. There would be classes of events for: a) creating a connection b) grabbing a connection c) closing a connection d) a connection getting too old ...whatever else. I haven't thought through all the types of events, but I think allowing an optional listener(s) to attach to the pool would be even better than spewing log messages out. We'd want to provide at leats one debugging pool-listener that prints debug messages. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
--- Serge Knystautas [EMAIL PROTECTED] wrote: David Graham wrote: The approach I took was this a) support an optional max-active time threshold, which means there is a time limit to how long a connection can be marked as in use. There is a maxActive property of BasicDataSource that defines the maximum number of open connections. Adding a time limit is reasonable if step b is changed below. b) if this threshold is exceeded, you close the connection. The value of trying to return it to the pool is minimal, while the downside of returning a mid-transaction/statement connection to a pool is very bad and nearly impossible to track down. DBCP should not close connections that have been borrowed from the pool. It should only log a possible error when the configured time limit has been exceeded. I *need* the pooler to close connections that have been borrowed from the pool and forgotten to be closed. Can you give a) reasons why not to close them because of an optional parameter and b) suggested workaround? This entire thread has been filled with reasons to not support closing abandoned connections. If you need to have this behavior, you will need to customize DBCP for your apps because it should not be built in. However, any app that needs a connection pool to clean up after it is highly suspect. I'm ok with this as long the stack trace isn't logged like an exception. It will be confusing for people to see a stack trace that isn't really associated with an exception so the message should indicate that it's identifying a possible connection leak location. I think there's a relunctance (including mine) to create a dependency on commons-logging (or another logger), so I was thinking about a PoolListener service. Many Jakarta projects use commons-logging to separate themselves from any particular logging implementation. Implementing listeners is over engineering what should be a simple solution. I believe commons-pool, on which DBCP is based, supports listeners for various events. David There would be classes of events for: a) creating a connection b) grabbing a connection c) closing a connection d) a connection getting too old ...whatever else. I haven't thought through all the types of events, but I think allowing an optional listener(s) to attach to the pool would be even better than spewing log messages out. We'd want to provide at leats one debugging pool-listener that prints debug messages. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
Serge, I *need* the pooler to close connections that have been borrowed from the pool and forgotten to be closed. Can you give a) reasons why not to close them because of an optional parameter and b) suggested workaround? Why? I can think of a couple of reasons you might give, but I'm seriously not convinced that it is a legitimate thing for the pool to do. Can you sell it to us? I think there's a relunctance (including mine) to create a dependency on commons-logging (or another logger), so I was thinking about a PoolListener service. FWIW I authored a JDBC connection pool and file URL cache library for work, my experience is this.. we started off with logging, it is vital to know exactly what the pools and caches think is going on while your library is under development. However once we started putting stable product into other software we quickly discovered that logging is unnecessary, if anything is going on you use a debugger, if it is going well you don't want the kind of logs these things produce. We eventually added a listener API and found it to be much more satisfactory. +1 to that idea. There would be classes of events for: a) creating a connection b) grabbing a connection c) closing a connection d) a connection getting too old I think that if in case d) your listener can intervene in the connection lifecycle then it is unnecessary to have DBCP frceably close connections. d.
Re: DBCP status?
ResultSet rs;
try {
con = magicGetConnection();
//stuff
} catch(...) {
} finally {
try {if (rs!=null){ rs.close(); rs=null; } } catch(Throwable ignore){}
try {if (ps!=null){ ps.close(); ps=null; } } catch(Throwable ignore){}
try {if (ps!=null){ con.close(); con=null; } } catch(Throwable
ignore){}
}
In the above code - I try to use the good practice of try-catch-finally.
My
code works great in the testing environment (of course it should fail in
stress testing in cases it can be done).
There are a lot of good ways to manage resources, but I think it is out of
DBCP scope.
Workarounds in pool can not help in this case too (try {if (ps!=null){
con.close(); con=null; } } catch(Throwable ignore){})
maxConnections = 1 can better help to find this kind of problems.
Let handle this stuff for JDBC frontends. Is is very easy to implement JDBC
resource management.
I use JDBC API this way at this time:
void method( String arg1, ){
JdbcUtils.executeSQL( SELECT ., new Object[]{ arg1 , ...},
new Callback(){
public void handle( ResultSet rs ){
handle results
}
}
);
}
There are a lot of opensource frameworks like IBATIS, Voruta,
SpringFramework, ... DbUtils in sandbox is a minimalist tool for JDBC API
too. It is very easy to learn and use this kind of frameworks, just add
links to JDBC frontends and it will solve database progamming problems
better.
I prefer pools without workarounds, it can help to find and fix problem. Do
not to hide problems, it solves nothing.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: DBCP status?
Hi, All! 1) A side-note It would be really more easy if this discussion was held somewhere on db-commons, really :-) 2) PS The EAI or network infrastructure, for example, behind one of the PS apps could cause it to grind to a halt, effectively orphaning any PS connections that it has open, depriving the other apps of these PS resources. Hey, there's one more solution! So far we have discussed two possible actions if a connection has not been returned to a pool too long: a) just log it as an error and do nothing b) forcibly bring it back to the pool But we can have c) here: c) log this as an error and no longer consider the connection as part of the pool! That is, if * the pool is configured to have 10 connections max * our too long not returned time out is configured to be 60 seconds * all 10 connections have been taken out * one of them has not been returned for over 60 seconds We just forget about the too long not returned connection and consider that our pool now has only 9 connections. This allows us to create one new connection and give it to the waiting clients. If afterwards the offending connection is returned after all there are two ways IMO to handle it i) not put back to pull at all, just close it uncoditionally ii) see how many connections we have in the pool, if we have bellow 10, add it to the pool, if we have all 10 already, close it as being excessive This solution leaves the abandoned connections to be reclaimed but the regular database timeout (8 hours for the standard MySQL setup) which is not that bad. This of course won't work too well if the database limits the number of connections available to, say 10, by the license, but I propose the following criteria: *** The situation when the pool is applied shouldn't be worse then it would be if we had no pool. *** Of course if maxActive is non-zero this criteria is not obeyed anyway, so my solution best applies if maxActive is 0. What to do if maxActive is positive I'm at a loss - Anton P.S. The following note by David Graham probably makes this behavior unnecessary, still I wanted to propose it. DG If your environment has the above characteristics, each DG application would have its own separate connection pool DG so a failure in one app would not affect another. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
I'm in the don't reclaim camp, but am thinking, IF somebody really wants it, then the solution would be to rollback and close the real connection -- this: * emulates a legal timeout from the database server * ensures any further action on by the rogue app will get a suitable exception * provides database side cleanup as a failure condition * won't impact performance of the pool, since the connection timeout is bound (?) to be way higher than the overhead of opening a new connection. I think this would alleviate much of the force-back-to-the-pool angst - force it to be closed for proper clean up while not hogging resources Anton Tagunov [EMAIL PROTECTED]To: Jakarta Commons Developers List [EMAIL PROTECTED] t.rucc: Subject: Re[2]: DBCP status? 30/06/2003 07:31 Please respond to Jakarta Commons Developers List Hi, All! 1) A side-note It would be really more easy if this discussion was held somewhere on db-commons, really :-) 2) PS The EAI or network infrastructure, for example, behind one of the PS apps could cause it to grind to a halt, effectively orphaning any PS connections that it has open, depriving the other apps of these PS resources. Hey, there's one more solution! So far we have discussed two possible actions if a connection has not been returned to a pool too long: a) just log it as an error and do nothing b) forcibly bring it back to the pool But we can have c) here: c) log this as an error and no longer consider the connection as part of the pool! That is, if * the pool is configured to have 10 connections max * our too long not returned time out is configured to be 60 seconds * all 10 connections have been taken out * one of them has not been returned for over 60 seconds We just forget about the too long not returned connection and consider that our pool now has only 9 connections. This allows us to create one new connection and give it to the waiting clients. If afterwards the offending connection is returned after all there are two ways IMO to handle it i) not put back to pull at all, just close it uncoditionally ii) see how many connections we have in the pool, if we have bellow 10, add it to the pool, if we have all 10 already, close it as being excessive This solution leaves the abandoned connections to be reclaimed but the regular database timeout (8 hours for the standard MySQL setup) which is not that bad. This of course won't work too well if the database limits the number of connections available to, say 10, by the license, but I propose the following criteria: *** The situation when the pool is applied shouldn't be worse then it would be if we had no pool. *** Of course if maxActive is non-zero this criteria is not obeyed anyway, so my solution best applies if maxActive is 0. What to do if maxActive is positive I'm at a loss - Anton P.S. The following note by David Graham probably makes this behavior unnecessary, still I wanted to propose it. DG If your environment has the above characteristics, each DG application would have its own separate connection pool DG so a failure in one app would not affect another. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
RE: DBCP status?
I think we've had this discussion before. But I'll weigh in with my 2c again because I still feel strongly about it.. Craig says: I do not believe there is any fundamentally sound algorithm that a connection pool can use to detect when a connection has truly been abandoned and is thereby suitable for recovery. And, grabbing back connections that are actually in use is *much* worse than leaking them, because you immediately break an application that is currenty executing, in ways that are very unpredictable, hard to reproduce, and basically impossible to recover from. I agree. IMO It is fundamentally better to let leaks result in the problems associated with leaks (run out of connections) than to replace a set of known, quantifiable and understood symptoms with Mystery and Confusion. d.
Re: DBCP status?
It is possible to detect abandoned connection with Thread.isAlive() (if thread pool is not used or maxConnections = maxThreads), but it is not a good way for performance ( iterate owners and chech isAlive ) - Original Message - From: Danny Angus [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, June 30, 2003 12:47 PM Subject: RE: DBCP status? I think we've had this discussion before. But I'll weigh in with my 2c again because I still feel strongly about it.. Craig says: I do not believe there is any fundamentally sound algorithm that a connection pool can use to detect when a connection has truly been abandoned and is thereby suitable for recovery. And, grabbing back connections that are actually in use is *much* worse than leaking them, because you immediately break an application that is currenty executing, in ways that are very unpredictable, hard to reproduce, and basically impossible to recover from. I agree. IMO It is fundamentally better to let leaks result in the problems associated with leaks (run out of connections) than to replace a set of known, quantifiable and understood symptoms with Mystery and Confusion. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: DBCP status?
Hello Ken! There have been very strongly argumented opinions that the pool should do nothing of the sort, but I'd like to go to the bottom of discussing other alternatives too. KH * emulates a legal timeout from the database server I have been stricken with the beauty of approach you have proposed, indeed its nice to emulate a server timeout :-)) I still have one reservation: its synchronization. Does this proposition mean that we have to make all the normal operations on the connections synchronized? I'm afraid something nasty may happen if while the user is executing a lengthy query another thread close()-s the connection. (I'm not concerned that we shall kill legitimate client operation - after all the client should have specified a longer timeout then, I'm concerned that we may upset the driver or something.) Another synchronization issue is that theoretically w/o a synchronization the fact that we have called close() on the connection is not guaranteed to be propagated to the other thread that is probably holding the connection. Unless the db driver does synchronization somewhere underneath of course. What do you think of this synchronization overhead? Negligible? - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: DBCP status?
Pool doe's not need locks on connection objects, synchronized can be used for wait/notifyAll, but it needs monitor of some global object. Pool must never return the same connection for different threads, but connection can be fail-fast itself, it is not a very big overhead for connection objects to call if(owner != Thread.currentThread()) throw new ConcurrentModificationException(); and to set owner at getConnection time. owner can be used for automagic, but I am a very big enemy for this kind of workarounds myself. Hello Ken! There have been very strongly argumented opinions that the pool should do nothing of the sort, but I'd like to go to the bottom of discussing other alternatives too. KH * emulates a legal timeout from the database server I have been stricken with the beauty of approach you have proposed, indeed its nice to emulate a server timeout :-)) I still have one reservation: its synchronization. Does this proposition mean that we have to make all the normal operations on the connections synchronized? I'm afraid something nasty may happen if while the user is executing a lengthy query another thread close()-s the connection. (I'm not concerned that we shall kill legitimate client operation - after all the client should have specified a longer timeout then, I'm concerned that we may upset the driver or something.) Another synchronization issue is that theoretically w/o a synchronization the fact that we have called close() on the connection is not guaranteed to be propagated to the other thread that is probably holding the connection. Unless the db driver does synchronization somewhere underneath of course. What do you think of this synchronization overhead? Negligible? - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: DBCP status?
I wouldn't bother with the synchronization -- closing the socket (which would (probably) be the effect of con.close()) would propagate the event. Obviously this would be driver dependent, and at best is still a bad thing to do -- to re-iterate, I'd only want DBCP to, at most, log abandoned connections. Re-claiming isstill asking for trouble. -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[4]: DBCP status?
Hello Juozas! JB Pool doe's not need locks on connection objects, synchronized can be used JB for wait/notifyAll, JB but it needs monitor of some global object. Pool must never return the JB same connection JB for different threads, but connection can be fail-fast itself, JB it is not a very big overhead for connection objects to call JB if(owner != Thread.currentThread()) JB throw new ConcurrentModificationException(); JB and to set owner at getConnection time. owner can be used for JB automagic, but I am a very big enemy for this kind of workarounds myself. Very pleased to see your mail :) It really has nice ideas in it! But, I've got a feeling that we're talking different languages here! In fact I was discussing Ken Horn's idea that the pool could * after a connection has been grabbed but not released, for say 10 minutes * forcibly close the underlying real connection (thus freeing db server's resources) or forcibly return the real connection to the pool * emulate a database server timeout for that connection by throwing an exception on any further client's call on the wrapping connection obtained from the pool It is a way to handle reclaiming lost connections. To do this we need a monitor thread that would track connections that have not been released too long. And for it to tear the real connection away from the wrapping connection after our 10 minutes timeout we synchronization as here we have two threads (client's and monitor's) possibly competing for access to the wrapping and real connections. That's what I have been talking about :-) -Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re[2]: DBCP status?
I have been stricken with the beauty of approach you have proposed, indeed its nice to emulate a server timeout :-)) I can see how this would appeal, allowing DBCP to impose its own timeout, however IMO it would still not allow DBCP be able to reclaim the connection, Rather it would have instead to mimic the servers response to a timeout, which might only become apparent when the connection is used, and not have any affect if the routine holding the connection is accessing properties and methods of the connection which are handled offline. In this event it would therefore appear to be almost impossible to achieve any real advantage for the pool, in that it would still not be able to legitimately reclaim the connection or close it, unless that can be done without breaking existing ResultSet's, StoredProcedures and so on. For example connecting to MySQL using JDBC it is possible to attempt to use a connection which no longer exists, and only on the execution of an SQL query does the driver return an error. This is because the instance of Connection is not closed, it is simply no longer capable of contacting the RDBMS. Even when that error is issued it is *still* the responsibility of the user to call close(), JDBC doesn't reclaim the object and garbage collect it for you. Therefore I contend that it would be inconsistent for DBCP to behave otherwise, and it would also be of little use for preventing leaks as leaked connections will most likely never be used again, and so never be seen to timeout. I'm afraid something nasty may happen if while the user is executing a lengthy query another thread close()-s the connection. This is one of my primary reasons for siding against intervention by the pool, it is not within the remit of a pool to dictate how the resources should be used. In use, IMO, any pool or cache should intervene between programme and resource in a manner which is completely transparent. It should never be the case that a pool or cache can cause the failure of the resource where the resource is being used legitimately according to its specification, JDBC makes no restriction on the length of time connections can be held for and therfore neither should any JDBC connection pool. If this causes problems for the user it is because they are either using the pool inapropriately or their code is broken. In neither situation has the case been well argued that the pool should attempt to correct this in preference to the developers of the software. d.
Re: Re[4]: DBCP status?
But, I've got a feeling that we're talking different languages here! In fact I was discussing Ken Horn's idea that the pool could * after a connection has been grabbed but not released, for say 10 minutes * forcibly close the underlying real connection (thus freeing db server's resources) or forcibly return the real connection to the pool Sorry, it is a crap and needs no discussions. * emulate a database server timeout for that connection by throwing an exception on any further client's call on the wrapping connection obtained from the pool I understand it and I see meaning in the last option only throwing an exception, it needs no synchronization. I will be very happy if nobody will add more workarounds to DBCP. That's what I have been talking about :-) -Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
David Graham wrote: The problem was that DBCP was trying to track and recover abandoned connections. This isn't just an implementation problem, it's a philosophy problem. Pool semantics dictate that client applications behave properly when checking out and returning pool resources. The pool is absolutely not responsible for fixing poorly behaving applications. This led to bugs, questions, convoluted inheritance hierachies/code, and promoted the idea that users didn't have to bother writing their applications properly because the pool would fix their apps for them. The pool should keep track of how long a connection has been checked out and log a message when it passes some configurable threshold but it should never try to grab the connection back from the application. I agree trying to recover connections is bad. I've found it leads to problems that don't show up during a test phase become very confusing and challenging problems in production once under high-load. The approach I took was this a) support an optional max-active time threshold, which means there is a time limit to how long a connection can be marked as in use. b) if this threshold is exceeded, you close the connection. The value of trying to return it to the pool is minimal, while the downside of returning a mid-transaction/statement connection to a pool is very bad and nearly impossible to track down. c) support an optional debug step that will create a Throwable when getConnection is called. Then if the max-active threshold is hit, we can print the stack trace of where the aged connection was grabbed, and in development/testing, quickly resolve the errant connection. Does this seem reasonable? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
I do not believe there is any fundamentally sound algorithm that a connection pool can use to detect when a connection has truly been abandoned and is thereby suitable for recovery. If we did not have a pool, the server would eventually (a) run out of connections, possibly impacting other applications in the system and/or (b) timeout excessively old connections. Those timeouts are generally very long. The default in MySQL is 8 hours. The question to ask is the purpose of a connection pool. If it is to improve performance, then it has a set of jobs. Changing the characteristics of the preceeding paragraph are not included in that set of jobs. Where people want a connection pool to recover abandoned connections, that usually points to either poor programming within a particular application, or sharing by multiple application components, one of which may have a problem. Essentially, they want to shorten the server timeout, so that other components can't deny service by losing track of connections. Do you concur with this analysis? It's really sad that people writing database driven software using a connection pool don't seem to be aware of how trivially simple it is to make sure that connection leaks do not happen to them, using a try/catch/finally block to ensure that the release always happens. I agree. The code that I use is even more that what you posted, so much so that it led me to develop a functor-type approach for our internal use, where I provide the normative database operation(s) that we want performed, and the core library manages the rest. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
--- Noel J. Bergman [EMAIL PROTECTED] wrote: I do not believe there is any fundamentally sound algorithm that a connection pool can use to detect when a connection has truly been abandoned and is thereby suitable for recovery. If we did not have a pool, the server would eventually (a) run out of connections, possibly impacting other applications in the system and/or (b) timeout excessively old connections. Those timeouts are generally very long. The default in MySQL is 8 hours. This configuration is well beyond the scope of DBCP. The question to ask is the purpose of a connection pool. If it is to improve performance, then it has a set of jobs. Changing the characteristics of the preceeding paragraph are not included in that set of jobs. Performance improvement is the main reason to use pooling. Where people want a connection pool to recover abandoned connections, that usually points to either poor programming within a particular application, or sharing by multiple application components, one of which may have a problem. Essentially, they want to shorten the server timeout, so that other components can't deny service by losing track of connections. Do you concur with this analysis? That is most likely why people want DBCP to recover connections but again this is beyond the scope of DBCP. Fixing the applications to manage their resources appropriately is the solution in this case. David It's really sad that people writing database driven software using a connection pool don't seem to be aware of how trivially simple it is to make sure that connection leaks do not happen to them, using a try/catch/finally block to ensure that the release always happens. I agree. The code that I use is even more that what you posted, so much so that it led me to develop a functor-type approach for our internal use, where I provide the normative database operation(s) that we want performed, and the core library manages the rest. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
That is most likely why people want DBCP to recover connections but again this is beyond the scope of DBCP. Fixing the applications to manage their resources appropriately is the solution in this case. +1 I prefer to remove all resource management workarounds from DBCP and use fail-fast way. It must help to solve problems not to hide them. David __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.491 / Virus Database: 290 - Release Date: 2003.06.21 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
--- Phil Steitz [EMAIL PROTECTED] wrote: David Graham wrote: --- Noel J. Bergman [EMAIL PROTECTED] wrote: David, I hope that you have not gotten the impression that I am arguing with you. Nope, I was just stating my point of view :-). I will continue to argue against recovering connections until someone can make a solid case that persuades me otherwise. Here is an attempt at making the case for some form or connection recycling or aggressive connection management. I have tried to address your main points, which I agree are the central ones. Please take this for what it is -- just another viewpoint based on what may be incomplete or incorrect understanding of what dbcp is trying to do. Here are the main problems: 1. Pools should not grab resources back from applications. Unless there is a contract that says that connections not used for more than a configurable Orphan timeout can be reclaimed. Are you ruling out this possibility? See for example, the configuration parameter called Orphan tiemout defined here: http://publib7b.boulder.ibm.com/wasinfo1/en/info/aes/ae/udat_was4poolset.html. Client apps are free to set the timeout to be effectively infinite if they want and connections enlisted in transactions are not reclaimed. Note that even if the pool doesn't do it, the engine eventually will timeout unused connections anyway. Of course if you define the pool contract that way then it is allowable. The separation of concerns I'm defining says that DBCP is responsible for maintaining a connection pool and clients are responsible for borrowing and returning connections. Putting connection reclamation into DBCP is an undue burden on it when the logical place for that responsibility is with the client. 2. Even if pools were allowed to do that, there is no algorithm for doing so in a reasonable manner. I agree that there is certainly no algorithm for divining when a connection has been abandoned by an application. If the pool has knowledge of when connections are being used, however, it can certainly enforce idle timeouts. If there is no sound algorithm, how can DBCP enforce idle timeouts? The most DBCP should do is log a possible connection leak because it lacks enough information to make a judgement about leaked connections. Only the client application has that information. This is also a reason why DBCP should not ship with a pluggable connection reclamation behavior. 3. There seem to be no reasons other than laziness or fear for wanting the pool to reclaim connections. Fear is a good thing for resource managers (or any other server component). What it comes down to here, IMHO, is what dbcp wants to be. If it wants to be a lightweight component used by single applications in a controlled environment, then it does not have to be robust against misbehaving clients, clients that abandon connections, or clients that hold idle connections too long. If the aim is something like Tomcat + dbcp = insert your favorite commercial container - EJBs, then it needs to be more robust. DBCP can be robust without reclaming connections. I am open to designing DBCP in such a way that allows people to plugin the behaviors they need including reclaming connections (the Strategy pattern may be useful here). However, DBCP should never provide that functionality out of the box because it implies that Jakarta supports poor programming practices. I disagree with the assertion that making the pool robust against abandoned connections supports poor programming practices. First, just because an API can be misused, that does not mean that the design of the API promotes or encourages the misuse. Second, in a shared environment, there may be situations in which connections get effectively abandoned without poor programming practices -- at least not in the database access code. The EAI or network infrastructure, for example, behind one of the apps could cause it to grind to a halt, effectively orphaning any connections that it has open, depriving the other apps of these resources. Here again, it depends on what the goal of dbcp is. If deployment in large scale apps in a shared environment is a goal, then it needs to aggressively manage resources. I disagree. If your environment has the above characteristics, each application would have its own separate connection pool so a failure in one app would not affect another. David Obviously, all of this is just my own point of view and since I have contributed nothing to dbcp, it should not carry much weight. If others feel the same way, however, and there is interest in either developing a pluggable strategy to support configurable connection recycling or other connection management extensions, I would be willing to help out. Phil I believe debate is a great way of coming to a solution. Thanks for
RE: DBCP status?
- Better support/debugging for forcing connections closed after being open for too long This is exactly what got DBCP into trouble in the past. I'm -1 on providing any ability in DBCP to close lost connections. DBCP should provide the ability to *log* when it detects a resource leak but the application is responsible for the health of the pool. I understand your view, but do you believe that there is no possible solution? If it is just an implementation concern, I'd just as soon see what solution someone comes up with. In your opinion, what are/were the problems in handling abandoned connections in DBCP? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
--- Noel J. Bergman [EMAIL PROTECTED] wrote: - Better support/debugging for forcing connections closed after being open for too long This is exactly what got DBCP into trouble in the past. I'm -1 on providing any ability in DBCP to close lost connections. DBCP should provide the ability to *log* when it detects a resource leak but the application is responsible for the health of the pool. I understand your view, but do you believe that there is no possible solution? If it is just an implementation concern, I'd just as soon see what solution someone comes up with. In your opinion, what are/were the problems in handling abandoned connections in DBCP? The problem was that DBCP was trying to track and recover abandoned connections. This isn't just an implementation problem, it's a philosophy problem. Pool semantics dictate that client applications behave properly when checking out and returning pool resources. The pool is absolutely not responsible for fixing poorly behaving applications. This led to bugs, questions, convoluted inheritance hierachies/code, and promoted the idea that users didn't have to bother writing their applications properly because the pool would fix their apps for them. The pool should keep track of how long a connection has been checked out and log a message when it passes some configurable threshold but it should never try to grab the connection back from the application. David --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
That's all well and nice until a request fires a condition where it doesn't close the connection and takes down the server or makes all requests fail due to an exhausted pool. Which can only be fixed on the short term by a webserver restart. Which is what a sysadmin will due, report it in a log and the root cause doesn't get fixed. I would be content to see it configurable to automagically close connections or just state a warning. For me this isn't an issue since I wrote my own pool for my employer, but I'd rather dump my code and use one with more mindshare like dbcp. If I do that - automagically killing connections will be essential. FWIW - in my pool code - I use a facade to mask the real dbms connection. If the too much time passes by - I close the real dbms connection(since the coder probably did lots of bad things) and set it to null so future attempts by the bad app immediately fails. In the context of a web request - this is acceptable for my situation. In hindsight - what I should do is throw a RuntimeException instead of having a NPE be thrown. The RuntimeException would have a nice message stating that the connection was closed because it was open too long. (I just thought of this 5 seconds ago, I haven't determined if its a good idea yet) I'll try to stay quiet now (and go back to lurking since I'm not really contributing to commons, I apologize to all if I sound like noise) Hopefully closer to the 4th quarter - I can help out. -Tim David Graham wrote: The pool should keep track of how long a connection has been checked out and log a message when it passes some configurable threshold but it should never try to grab the connection back from the application. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
The code was buggy and added complexity both in and out of the AbandonedConnectionPool. Some would argue that recovering from programmer error is not an appropriate role for a component like DBCP, and for what it's worth, I think I'm probably one of those. That said, I think changing dbcp/pool to be more compositional and less extend-to-customize-oriented would be a good move all around, and should make it possible to add abandoned object recovery (or abandoned object logging, or a host of other things) as a decorator--which should make it orthogonal to the other implementations/concerns. - Rod http://radio.weblogs.com/0122027/ On Sat, 28 Jun 2003, Noel J. Bergman wrote: - Better support/debugging for forcing connections closed after being open for too long This is exactly what got DBCP into trouble in the past. I'm -1 on providing any ability in DBCP to close lost connections. DBCP should provide the ability to *log* when it detects a resource leak but the application is responsible for the health of the pool. I understand your view, but do you believe that there is no possible solution? If it is just an implementation concern, I'd just as soon see what solution someone comes up with. In your opinion, what are/were the problems in handling abandoned connections in DBCP? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
--- Rodney Waldhoff [EMAIL PROTECTED] wrote: The code was buggy and added complexity both in and out of the AbandonedConnectionPool. Some would argue that recovering from programmer error is not an appropriate role for a component like DBCP, and for what it's worth, I think I'm probably one of those. That said, I think changing dbcp/pool to be more compositional and less extend-to-customize-oriented would be a good move all around, and should make it possible to add abandoned object recovery (or abandoned object logging, or a host of other things) as a decorator--which should make it orthogonal to the other implementations/concerns. Recovering lost connections whether implemented with a class hierarchy or composition is an extremely bad idea. If DBCP is designed to allow pluggable behaviors in general and someone decides to implement connection recovery for their application, that's their problem. We shouldn't be promoting poor practices by supporting connection recovery directly from DBCP. David - Rod http://radio.weblogs.com/0122027/ On Sat, 28 Jun 2003, Noel J. Bergman wrote: - Better support/debugging for forcing connections closed after being open for too long This is exactly what got DBCP into trouble in the past. I'm -1 on providing any ability in DBCP to close lost connections. DBCP should provide the ability to *log* when it detects a resource leak but the application is responsible for the health of the pool. I understand your view, but do you believe that there is no possible solution? If it is just an implementation concern, I'd just as soon see what solution someone comes up with. In your opinion, what are/were the problems in handling abandoned connections in DBCP? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
--- Tim Funk [EMAIL PROTECTED] wrote: That's all well and nice until a request fires a condition where it doesn't close the connection and takes down the server or makes all requests fail due to an exhausted pool. Which can only be fixed on the short term by a webserver restart. Which is what a sysadmin will due, report it in a log and the root cause doesn't get fixed. If one of your apps can take down your whole server, nothing we could do in DBCP will help you. Not closing connections is one of many bugs that can occur in an application and the prevention of those bugs is not DBCP's responsibility. The detection and notification of lost connections should be DBCP's responsibility to speed debugging. David I would be content to see it configurable to automagically close connections or just state a warning. For me this isn't an issue since I wrote my own pool for my employer, but I'd rather dump my code and use one with more mindshare like dbcp. If I do that - automagically killing connections will be essential. FWIW - in my pool code - I use a facade to mask the real dbms connection. If the too much time passes by - I close the real dbms connection(since the coder probably did lots of bad things) and set it to null so future attempts by the bad app immediately fails. In the context of a web request - this is acceptable for my situation. In hindsight - what I should do is throw a RuntimeException instead of having a NPE be thrown. The RuntimeException would have a nice message stating that the connection was closed because it was open too long. (I just thought of this 5 seconds ago, I haven't determined if its a good idea yet) I'll try to stay quiet now (and go back to lurking since I'm not really contributing to commons, I apologize to all if I sound like noise) Hopefully closer to the 4th quarter - I can help out. -Tim David Graham wrote: The pool should keep track of how long a connection has been checked out and log a message when it passes some configurable threshold but it should never try to grab the connection back from the application. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
On Sat, 28 Jun 2003, Noel J. Bergman wrote:
Date: Sat, 28 Jun 2003 14:34:05 -0400
From: Noel J. Bergman [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: RE: DBCP status?
- Better support/debugging for forcing connections closed after being
open for too long
This is exactly what got DBCP into trouble in the past. I'm -1 on
providing any ability in DBCP to close lost connections. DBCP should
provide the ability to *log* when it detects a resource leak but the
application is responsible for the health of the pool.
I understand your view, but do you believe that there is no possible
solution? If it is just an implementation concern, I'd just as soon see
what solution someone comes up with. In your opinion, what are/were the
problems in handling abandoned connections in DBCP?
I agree with David (and others who think a pool trying to recover things
is a bad idea).
I do not believe there is any fundamentally sound algorithm that a
connection pool can use to detect when a connection has truly been
abandoned and is thereby suitable for recovery. And, grabbing back
connections that are actually in use is *much* worse than leaking them,
because you immediately break an application that is currenty executing,
in ways that are very unpredictable, hard to reproduce, and basically
impossible to recover from.
It's really sad that people writing database driven software using a
connection pool don't seem to be aware of how trivially simple it is to
make sure that connection leaks do not happen to them, using a
try/catch/finally block to ensure that the release always happens.
DataSource ds = ... reference to your pool ...;
Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
// Allocate a connection from the pool
conn = ds.getConnection();
// Use it to perform some processing -- either directly
stmt = conn.prepareStatement(SELECT ...);
rs = stmt.executeQuery();
while (rs.next()) {
... process this row ...
}
rs.close();
rs = null;
stmt.close();
stms = null;
// Or pass the allocated connection on to some other method
doMyDatabaseTransaction(conn);
// Keep doing transactions on this connection until you are done
} finally {
// Release allocated resources, no matter what exception was thrown
if (rs != null) {
try {
rs.close();
} catch (SQLException e) {
; // Or log it
}
rs = null;
}
if (stmt != null) {
try {
stms.close();
} catch (SQLException e) {
; // Or log it
}
stmt = null;
}
if (conn != null) {
try {
conn.close(); // Returns connection to the pool
} catch (SQLException e) {
; // Or log it
}
conn = null;
}
}
--- Noel
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: DBCP status?
Hi, all! JMcN I am the primary developer of the jdbc2pool and cpdsadapter packages. JMcN I do not see any reason to merge the code into one package with the rest JMcN of dbcp. They seem packaged appropriately to me. The main thing that JMcN needs to be done here is to rename the jdbc2 in the names to something JMcN else. I don't know what is a better name, but we should not release JMcN with jdbc in the class or package names. Have looked at jdbc2pool a couple of weeks ago (we have probably both participated in the bugzilla discussion, didn't we? :) To me jdbc2pool looked not ready for a release. On the other hand cpdsadapter and the rest of dbcp looked like after a bit of work (in which Serge Knystautas will probably participate :-) they will be quite ready for a release. Do you agree? (That there may be a release soon, but without jdbc2 part, not to hold the progress ?) JMcN If anyone wants to become an active developer on dbcp, they are welcome Not right now, but the subject is certainly hot :-) DG As for the deluge of commons-dev mail, it has been suggested DG that DBCP move to db-commons which would alleviate that problem. Is there much chance this will happen? SK Anybody know what Tomcat is using at this point? Indeed would be interesting to see that :-) - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Hello Serge! SK Is anyone working on DBCP or planning another release anytime soon? SK It's been almost a year, and the project seems pretty inactive. Lurker's 0.02$ Have looked a couple of weeks ago * jdbc2 part seemed out of operation to me (just can't go into a release) * all the rest probably can (haven't investigated closely) - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
DBCP has 5 open bugs. I recently was looking at 18905 and modified some test code so that it is possible to reproduce. I did not get to the solution, so the test is not activated. It looks like 20649, could be resolved in some fashion by removing the use of AbandonedObjectPool. Getting rid of this code has already been proposed and agreed upon, if someone wants to submit a patch to do so. But the bug is only 2 weeks old, I don't think it can be declared as suffering from neglect. I am the primary developer of the jdbc2pool and cpdsadapter packages. I do not see any reason to merge the code into one package with the rest of dbcp. They seem packaged appropriately to me. The main thing that needs to be done here is to rename the jdbc2 in the names to something else. I don't know what is a better name, but we should not release with jdbc in the class or package names. If anyone wants to become an active developer on dbcp, they are welcome, but I think having at least one patch submitted before people start calling for a vote on new committers should be a minimum. Remember that once you are a committer on dbcp, you too get to subscribe to the deluge known as [EMAIL PROTECTED] in order to watch for the one email a month that might be related to a problem or question on dbcp. john mcnally On Sun, 2003-06-22 at 19:33, David Graham wrote: DBCP is very inactive. Struts dropped it from the distribution due to the lack of development support. David Is anyone working on DBCP or planning another release anytime soon? It's been almost a year, and the project seems pretty inactive. I was trying to integrate DBCP into James this weekend to replace my home-rolled DB connection, and after the fact realized that DBCP cannot handle database restarts as without a validate SQL statement, DBCP doesn't realize connections are corrupt and keeps putting them back in the pool. Would anyone be interested in me supplying some patches to do some extra checking, get some examples and documentation straight (I found 3 or 4 different basic examples, none of which worked for me)? Are other Apache projects using DBCP at this point, and is it reasonable to remove methods that have not been implemented (like setLoginTimeout())? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
--- John McNally [EMAIL PROTECTED] wrote: DBCP has 5 open bugs. I recently was looking at 18905 and modified some test code so that it is possible to reproduce. I did not get to the solution, so the test is not activated. It looks like 20649, could be resolved in some fashion by removing the use of AbandonedObjectPool. Getting rid of this code has already been proposed and agreed upon, if someone wants to submit a patch to do so. But the bug is only 2 weeks old, I don't think it can be declared as suffering from neglect. I am the primary developer of the jdbc2pool and cpdsadapter packages. I do not see any reason to merge the code into one package with the rest of dbcp. They seem packaged appropriately to me. The main thing that needs to be done here is to rename the jdbc2 in the names to something else. I don't know what is a better name, but we should not release with jdbc in the class or package names. If anyone wants to become an active developer on dbcp, they are welcome, but I think having at least one patch submitted before people start calling for a vote on new committers should be a minimum. Remember that once you are a committer on dbcp, you too get to subscribe to the deluge known as [EMAIL PROTECTED] in order to watch for the one email a month that might be related to a problem or question on dbcp. Normally I would agree with this but there isn't anyone around to apply patches. DBCP needs new developers and I'm delighted that several existing Apache folks have volunteered. As for the deluge of commons-dev mail, it has been suggested that DBCP move to db-commons which would alleviate that problem. David john mcnally On Sun, 2003-06-22 at 19:33, David Graham wrote: DBCP is very inactive. Struts dropped it from the distribution due to the lack of development support. David Is anyone working on DBCP or planning another release anytime soon? It's been almost a year, and the project seems pretty inactive. I was trying to integrate DBCP into James this weekend to replace my home-rolled DB connection, and after the fact realized that DBCP cannot handle database restarts as without a validate SQL statement, DBCP doesn't realize connections are corrupt and keeps putting them back in the pool. Would anyone be interested in me supplying some patches to do some extra checking, get some examples and documentation straight (I found 3 or 4 different basic examples, none of which worked for me)? Are other Apache projects using DBCP at this point, and is it reasonable to remove methods that have not been implemented (like setLoginTimeout())? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Serge, I'm using DBCP in a production environment. It actually does support validation queries to detect whether a connection is bogus or not. You just need to call setValidationQuery() on the PoolableConnectionFactory, and enable testOnBorrow on the ObjectPool you pass to the DBCP init stuff. I can provide sample code if you'd like. But like David said earlier, DBCP is pretty much a dead project. It works well enough for my needs, but I'm not sure I'd integrate it into a project right now. On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. -- Mark Lewis On Sun, 2003-06-22 at 19:06, Serge Knystautas wrote: Is anyone working on DBCP or planning another release anytime soon? It's been almost a year, and the project seems pretty inactive. I was trying to integrate DBCP into James this weekend to replace my home-rolled DB connection, and after the fact realized that DBCP cannot handle database restarts as without a validate SQL statement, DBCP doesn't realize connections are corrupt and keeps putting them back in the pool. Would anyone be interested in me supplying some patches to do some extra checking, get some examples and documentation straight (I found 3 or 4 different basic examples, none of which worked for me)? Are other Apache projects using DBCP at this point, and is it reasonable to remove methods that have not been implemented (like setLoginTimeout())? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. It doesn't appear to be implemented yet. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18012 David -- Mark Lewis On Sun, 2003-06-22 at 19:06, Serge Knystautas wrote: Is anyone working on DBCP or planning another release anytime soon? It's been almost a year, and the project seems pretty inactive. I was trying to integrate DBCP into James this weekend to replace my home-rolled DB connection, and after the fact realized that DBCP cannot handle database restarts as without a validate SQL statement, DBCP doesn't realize connections are corrupt and keeps putting them back in the pool. Would anyone be interested in me supplying some patches to do some extra checking, get some examples and documentation straight (I found 3 or 4 different basic examples, none of which worked for me)? Are other Apache projects using DBCP at this point, and is it reasonable to remove methods that have not been implemented (like setLoginTimeout())? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
Howdy, Yes, but that doubles the # of SQL statements. And I actually have probably no more than 8 SQL statements in total (all prepared), so the issue is not the SQL but the connection. Is there another way to check that a connection is bad, other than a validation query? AFAIK this is the standard way, and the above argument that using validation queries doubles the number of SQL statement doesn't matter that much. Validation queries are supposed to be quick, small, etc. Do you know of anything else in Apache that could handle this? Anybody know what Tomcat is using at this point? Tomcat doesn't have built-in connection pooling, but a mechanism for users to plug in their own. Many people use DBCP, and tomcat provides a HOW-TO: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-examples -howto.html I wouldn't rush to declare DBCP dead. Database connection pooling is not exactly the most revolutionary development area right now: DBCP is good at what it does, is being used widely, and I personally am not aware of anything that required a DBCP release within the past year. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Shapira, Yoav wrote: I wouldn't rush to declare DBCP dead. Database connection pooling is not exactly the most revolutionary development area right now: DBCP is good at what it does, is being used widely, and I personally am not aware of anything that required a DBCP release within the past year. That's somewhat encouraging about Tomcat using it (or at least mentions it first). Since James really does need a new connection pooler, and I'm stuck having to invest some time into making **some** database pooler more robust, is the DBCP project open to this? I'm not sure if there are any committers remaining, or what exactly is the next step. Basically I would make the following changes: - Allow the pool to optionally close a connection on a SQL exception (since that will often corrupt the transaction and/or indicate the connection is boofed). - Change some default values so it doesn't block indefinitely to open a connection out of the box. - Maybe support a connection factory constructor that can take a String for a driver name, rather than require you to do Class.forName() separately. - Maybe implement login timeout. - Maybe implement logging via commons logging so you can catch events rather than just use a writer. - Make a formal new release (either 1.1 or 2.0, I don't care), just so the examples, test code, and javadoc (in distro and website) all have working examples. Any feedback on these changes, or people I should talk to before heading down this road? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
Howdy, Since James really does need a new connection pooler, and I'm stuck having to invest some time into making **some** database pooler more robust, is the DBCP project open to this? I'm not sure if there are any I'm positive no one would oppose you contributing and working on it ;) - Allow the pool to optionally close a connection on a SQL exception (since that will often corrupt the transaction and/or indicate the connection is boofed). - Change some default values so it doesn't block indefinitely to open a connection out of the box. - Maybe support a connection factory constructor that can take a String for a driver name, rather than require you to do Class.forName() separately. - Maybe implement login timeout. - Maybe implement logging via commons logging so you can catch events rather than just use a writer. - Make a formal new release (either 1.1 or 2.0, I don't care), just so the examples, test code, and javadoc (in distro and website) all have working examples. The above ideas all seem cool to various degrees. I dislike the commons-logging one, as that may cause some problems for people using DBCP who don't want to use commons-logging. But testing can iron that out and I don't think it'll be a showstopper ultimately. Any feedback on these changes, or people I should talk to before heading down this road? You already have the above list; I would start by entering them as DBCP enhancement requests in bugzilla. Then start working them and send in patches to the mailing list (appropriately marking the subject lines, i.e. [DBCP][PATCH]). The committers will comment... Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Serge Knystautas wrote: Since James really does need a new connection pooler, and I'm stuck having to invest some time into making **some** database pooler more robust, is the DBCP project open to this? I'm not sure if there are any committers remaining, or what exactly is the next step. Basically I would make the following changes: - Allow the pool to optionally close a connection on a SQL exception (since that will often corrupt the transaction and/or indicate the connection is boofed). We are using DBCP in an application that has not yet gone to production, but is in active development; and we could definitely use this feature. Of course, I could just hack the source and implement it myself, but I've been too lazy thus far. :) Anyway, just wanted to let you know that your proposed enhancements would be much appreciated by the user community! - Maybe implement logging via commons logging so you can catch events rather than just use a writer. This would be nice, too: we're using C-L in our app. - Make a formal new release (either 1.1 or 2.0, I don't care), just so the examples, test code, and javadoc (in distro and website) all have working examples. That would all be just great! Hoping you decide to go this route, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Noel J. Bergman wrote: Martin Poeschl [EMAIL PROTECTED] wrote: dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. db.apache.org is a good location for a db connection pool, isn't it? when the db projects was started the idea was to have one place for all db related projects like torque, ojb, commons-dbcp, commons-sql, ... torque and ojb are already there ... if a new group of developers starts to work on dbcp i think it's a good chance to do the movement ... martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. i'd say that there will probably be quite a difference in atmosphere between the two sub-projects. developing in the jakarta commons means putting up with folks here, subscribing to the commons-dev mailing list (which is pretty high volume) but is high visibility. db-commons should be quieter and more focused on database components. if people think that moving would be a good idea, then it'd probably be a good idea to check first with the existing committers (probably a VOTE would be a good way to handle it). so i suppose that the first step should really be to propose a VOTE to elect noel as a commons committer. i'd prefer it if it came from one of the existing DBCP committers but if no one steps up sometime soonish i'll set something in motion. - robert On Monday, June 23, 2003, at 11:03 PM, Noel J. Bergman wrote: Martin Poeschl [EMAIL PROTECTED] wrote: dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. db.apache.org is a good location for a db connection pool, isn't it? when the db projects was started the idea was to have one place for all db related projects like torque, ojb, commons-dbcp, commons-sql, ... I'm sure it would be, yes. And if that's where people want it, I'll be happy to check it out from there and subscribe to that list. My only point is that I'd like to see the work start, and not get bogged down in any argument (*IF* there is one) about where to have the code. If it moves or stays, either way is fine with me. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Noel J. Bergman [EMAIL PROTECTED] writes: Martin Poeschl [EMAIL PROTECTED] wrote: dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. If Martin wants to work on it, I'm all +1 . Better than letting the code rot in (jakarta-)commons. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire --- Quote of the week: It is pointless to tell people anything when you know that they won't process the message. --- Jonathan Revusky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
I think that poolman had been end-of-lifed, and many of it's ideas went into DBCP. Eric -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 5:16 PM To: Jakarta Commons Developers List Subject: Re: DBCP status? On Mon, 23 Jun 2003, Serge Knystautas wrote: Mark Lewis wrote: Serge, I'm using DBCP in a production environment. It actually does support validation queries to detect whether a connection is bogus or not. Yes, but that doubles the # of SQL statements. And I actually have probably no more than 8 SQL statements in total (all prepared), so the issue is not the SQL but the connection. I can provide sample code if you'd like. But like David said earlier, DBCP is pretty much a dead project. It works well enough for my needs, but I'm not sure I'd integrate it into a project right now. Do you know of anything else in Apache that could handle this? Anybody know what Tomcat is using at this point? This isn't an Apache project (although one of the admins is an Apache guy ;), but you might want to look at PoolMan: http://sourceforge.net/projects/poolman/ -- Martin Cooper On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. We'd like that feature as well (since like I say we have so few SQL statements), but that's a bummer if it's broken. From the API it seems like it would work. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
did geir once suggest bringing poolman to apache? does anyone remember what happened about that? - robert On Tuesday, June 24, 2003, at 12:08 AM, [EMAIL PROTECTED] wrote: I think that poolman had been end-of-lifed, and many of it's ideas went into DBCP. Eric -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 5:16 PM To: Jakarta Commons Developers List Subject: Re: DBCP status? On Mon, 23 Jun 2003, Serge Knystautas wrote: Mark Lewis wrote: Serge, I'm using DBCP in a production environment. It actually does support validation queries to detect whether a connection is bogus or not. Yes, but that doubles the # of SQL statements. And I actually have probably no more than 8 SQL statements in total (all prepared), so the issue is not the SQL but the connection. I can provide sample code if you'd like. But like David said earlier, DBCP is pretty much a dead project. It works well enough for my needs, but I'm not sure I'd integrate it into a project right now. Do you know of anything else in Apache that could handle this? Anybody know what Tomcat is using at this point? This isn't an Apache project (although one of the admins is an Apache guy ;), but you might want to look at PoolMan: http://sourceforge.net/projects/poolman/ -- Martin Cooper On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. We'd like that feature as well (since like I say we have so few SQL statements), but that's a bummer if it's broken. From the API it seems like it would work. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. I didn't expect that there would be a problem. i suppose that the first step should really be to propose a VOTE to elect noel as a commons committer. Whoops. Thanks, but don't forget Serge, who is the James PMC Chair, and the one who started this thread. :-) developing in the jakarta commons means putting up with folks here, subscribing to the commons-dev mailing list (which is pretty high volume) but is high visibility. db-commons should be quieter and more focused on database components. I'm good either way. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
Subject: Re: DBCP status? did geir once suggest bringing poolman to apache? does anyone remember what happened about that? There was not enough support for the move. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
On Mon, 23 Jun 2003 [EMAIL PROTECTED] wrote: I think that poolman had been end-of-lifed, and many of it's ideas went into DBCP. No, it wasn't end-of-life'd. What happened was that the original developer decided he didn't want to continue to support it by himself at its own web site. Geir offered to help out, so it's now maintained (?) only at the SF site. (The '?' is because there isn't evidence of activity there, but then it's supposedly pretty stable anyway.) -- Martin Cooper Eric -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 5:16 PM To: Jakarta Commons Developers List Subject: Re: DBCP status? On Mon, 23 Jun 2003, Serge Knystautas wrote: Mark Lewis wrote: Serge, I'm using DBCP in a production environment. It actually does support validation queries to detect whether a connection is bogus or not. Yes, but that doubles the # of SQL statements. And I actually have probably no more than 8 SQL statements in total (all prepared), so the issue is not the SQL but the connection. I can provide sample code if you'd like. But like David said earlier, DBCP is pretty much a dead project. It works well enough for my needs, but I'm not sure I'd integrate it into a project right now. Do you know of anything else in Apache that could handle this? Anybody know what Tomcat is using at this point? This isn't an Apache project (although one of the admins is an Apache guy ;), but you might want to look at PoolMan: http://sourceforge.net/projects/poolman/ -- Martin Cooper On a related note, does anybody know what the status of PreparedStatement pooling is in the latest DBCP release? It seems broken to me, but I might be doing something wrong. We'd like that feature as well (since like I say we have so few SQL statements), but that's a bummer if it's broken. From the API it seems like it would work. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. Noel, forgive my ignorance but are you an existing committer? I'll nominate you to the commons based on Robert's apparent faith in you ;-). i'd say that there will probably be quite a difference in atmosphere between the two sub-projects. developing in the jakarta commons means putting up with folks here, subscribing to the commons-dev mailing list (which is pretty high volume) but is high visibility. db-commons should be quieter and more focused on database components. if people think that moving would be a good idea, then it'd probably be a good idea to check first with the existing committers (probably a VOTE would be a good way to handle it). so i suppose that the first step should really be to propose a VOTE to elect noel as a commons committer. i'd prefer it if it came from one of the existing DBCP committers but if no one steps up sometime soonish i'll set something in motion. I took a crack at fixing DBCP for Struts 1.1 and decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. Here is my wish list for DBCP in no particular order: - Delete the org.apache.commons.jocl package because it's no longer used/needed. - Analyze the o.a.c.dbcp.cpdsadapter and o.a.c.dbcp.jdbc2pool packages/classes and refactor any useful ideas into the main o.a.c.dbcp package. - We deprecated all the Abandoned* classes and related functionality but it still needs to be removed. It was an absolutely terrible idea to try and recover connections from poorly written client applications. Adding this to DBCP only increased the number of bugs. I do think logging potential connection leaks is appropriate but it's the application's responsibilty to not lose connections. - All of the Delegating* classes need to be returned to their pure delegate state. Functionality was added that lead to synchronization problems and wasn't in the spirit of a delegate class. - Standardize the coding conventions to the Sun Java guidelines. Most DBCP code follows it but some classes don't. Also, drop the hideous _var notation for instance variables. In combination these problems make the code uglier, harder to read, and thus harder to maintain. I would really like to see DBCP be a production quality connection pooling package so I'm really glad some more people are willing to take care of it. David - robert On Monday, June 23, 2003, at 11:03 PM, Noel J. Bergman wrote: Martin Poeschl [EMAIL PROTECTED] wrote: dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons?? Martin, so long as we get commit access, does it really matter which module? I view location as orthogonal. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
David Graham wrote: I took a crack at fixing DBCP for Struts 1.1 and decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. Here is my wish list for DBCP in no particular order: Thanks David. I'll add these to the list of changes I posted and will get it done shortly. They all seem very reasonable and helped confirm that there was unnecessary duplication in the codebase. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. Noel, forgive my ignorance but are you an existing committer? I'll nominate you to the commons based on Robert's apparent faith in you ;-). No worries. :-) There are, after all, close to 700 of us now. What I do if I don't know is log in and use finger. Serge, Martin Poeschl and I are all Committers. I took a crack at fixing DBCP [and] decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. I would really like to see DBCP be a production quality connection pooling package so I'm really glad some more people are willing to take care of it. Are you still willing to pitch in and help (or kibbitz), now that you've got company? Here is my wish list for DBCP in no particular order: I'm keeping a copy of your message for future reference. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
David Graham wrote: I took a crack at fixing DBCP for Struts 1.1 and decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. Here is my wish list for DBCP in no particular order: Thanks David. I'll add these to the list of changes I posted and will get it done shortly. They all seem very reasonable and helped confirm that there was unnecessary duplication in the codebase. Neat. I wish I could help out more but Struts and Validator are consuming all of my volunteer time right now. The main problem with DBCP seems to have been a drop and run approach to adding code. It really needs a steady team to maintain it. David -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem. Noel, forgive my ignorance but are you an existing committer? I'll nominate you to the commons based on Robert's apparent faith in you ;-). No worries. :-) There are, after all, close to 700 of us now. What I do if I don't know is log in and use finger. Serge, Martin Poeschl and I are all Committers. Thanks for the tip. I took a crack at fixing DBCP [and] decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons. I would really like to see DBCP be a production quality connection pooling package so I'm really glad some more people are willing to take care of it. Are you still willing to pitch in and help (or kibbitz), now that you've got company? I'm willing to help where I can but Struts and Validator are consuming my volunteer time right now. If there were only more hours in the day... David Here is my wish list for DBCP in no particular order: I'm keeping a copy of your message for future reference. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP status?
DBCP is very inactive. Struts dropped it from the distribution due to the lack of development support. David Is anyone working on DBCP or planning another release anytime soon? It's been almost a year, and the project seems pretty inactive. I was trying to integrate DBCP into James this weekend to replace my home-rolled DB connection, and after the fact realized that DBCP cannot handle database restarts as without a validate SQL statement, DBCP doesn't realize connections are corrupt and keeps putting them back in the pool. Would anyone be interested in me supplying some patches to do some extra checking, get some examples and documentation straight (I found 3 or 4 different basic examples, none of which worked for me)? Are other Apache projects using DBCP at this point, and is it reasonable to remove methods that have not been implemented (like setLoginTimeout())? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
