Serge Knystautas wrote: > > ----- Original Message ----- > From: "giacomo" <[EMAIL PROTECTED]> > > > The HardResourceLimitingPool was choosen because of licensing issues you > > might run into when creating more connection than you've licensed. This > > way you can be sure you want run into illegality ;) > > Ok sure, illegality is a bad thing. > > I guess I have different a expectation of a datasource. I'm used to a > temporary unavailability being handled by the connection pooler, not by the > application. Are there other connection poolers out there that offer this > unreliability?
My initial attempts to provide a BlockingHardResourceLimitingPool (i.e. one that waits until something is released) resulted in DeadLock in certain circumstances. This is IMO a bad thing--because once you have deadlock, you can't get ANY more connection objects. For the interim solution, I have opted for the fail early approach. I have not had the time to debug the Blocking version. > On an unrelated note, I see in Jdbc2Connection (and Jdbc3Connection) there's > a m_num_uses which seems to cap the number of times a connection is used to > 15. What's the rationale behind this? I'd rather go through hundreds of > thousands of statements before it's closed...if my SQL is good, it might > take 1ms to run, and some servers take 1000ms to connect. So by capping it > to num uses to 15, I've got from 1ms/query to 67ms/query. Just seems like a > weird approach. :) I know it seems to be a weird approach, however I have found in dealing with Blobs that most JDBC drivers are buggy. For instance, if you happen to look for a Blob, and receive an exception because you tried to download a null blob, the Connection is now useless. Also, if there is some inconsistency in your code where all the JDBC objects are not properly closed by your application, you will find that the Connection object again becomes unusable. It is exhausting work to audit your own code much less everyone else's. I could set a flag so that when the Connection produces an Exception, that it gets recycled--but that means if your SQL is bad, you get a new connection everytime you execute it. Not optimal either. Eventually, I should make this cut-off configurable--but with testing in my environment, the setting I have works for everything. If you have suggestions, patches, example code, etc. I would be more than happy to evaluate them and incorporate them in the pooling code. Eventually, I want to pool the PreparedStatement objects as well (since the JDBC driver specs state that it is possible and provides additional performance). > > Serge Knystautas > Loki Technologies - Unstoppable Websites > http://www.lokitech.com/ > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
