• named (unregistered)

    wrist!

  • my name (unregistered)

    And yes, they implemented their own connection pooling, despite Java already having a perfectly good solution for it.

    been a while since I did anything serious in Java, but since when does Java provide connection pooling out of the box? I'm talking of course Java SE, don't know about JEE

  • (nodebb)

    Someone just picked a config number, and didn't think about anything else.

    I suspect nobody thought about anything when developing this code.

  • (nodebb)

    if(commentIndex() == "thrid") Application.Exit(0);

  • (author) in reply to my name

    It's also been a long minute for me, but my recollection is that most JDBC drivers implement it internally. I suppose they could be using a JDBC driver that doesn't, but that seems implausible to me.

  • LZ79LRU (unregistered)

    A bad developer ignores built in solutions in favor of his own.

    A real expert rolls his own and makes sure to completely follow all the interfaces of the built in stuff and use similar names (same names different namespace for best results). And than makes his version do half the things and with double the bugs. Also, make sure to only ever use the custom stuff as a recompiled library and loose or better yet partially loose the source.

    Don't ask me how I know...

  • Rob (unregistered)

    Most JDBC drivers I know don't support connection pooling. However, considering that this is a JEE service, it should be running on an application service like JBoss/WildFly, Glassfish, WebLogic, etc. All of these provide database connection management, including connection pooling. After that all you need to do is inject a DataSource, and get its connections from there

  • Rob (unregistered)

    I'd like to give bonus points for terrible formatting. No space after the "if", but instead extra spaces between each pair of brackets. And don't forget the extra parentheses on the first line...

  • Jason Stringify (unregistered) in reply to LZ79LRU

    *lose *lose

  • (nodebb)

    Agree the spaces after ( and befioe ) are unusual; I'm not sure I've ever seen that in the wild.

    But here they're employed consistently and they do serve the purpose of clearly separating the operand from the statement/operator. I find I sort of like that look & feel. Makes visually scanning the code for whatever you're seeking a bit easier than the "cram it all as tightly together as the parser will accept" method.

  • r (unregistered)

    JDBC drivers do not have connection pooling built in. You have to adopt some implementation of connection pooling if you want it.

    Further, if this code were written in say 2000 or so, then you really did have to build your own connection pooling unless you really wanted to use one of the commercial products or server products.

  • Oracles (unregistered) in reply to LZ79LRU

    "makes his version do half the things"

    Don't forget he also adds some subtle "extensions", too, making it a nightmare to port back to the built-in functions.

  • (nodebb)

    There was a connection leak. This is an epic kludge fix.

  • (nodebb)

    He's half right though. If there are too many connections, we should do something and not just keep opening more and more. This is a problem we encounter frequently. What they did, of course, is the absolute worst solution. What would be good is to reject traffic over some threshold, so that at least traffic under the threshold can still be served. But that's difficult to do correctly I guess.

  • (nodebb) in reply to WTFGuy

    It's how I do mine.

    My ( and ), [ and ], { and } demand their own airspace, no infringing on it!!!

  • Airdrik (unregistered)
    Comment held for moderation.
  • erffrfez (unregistered)
    Comment held for moderation.
  • erffrfez (unregistered) in reply to Rob
    Comment held for moderation.

Leave a comment on “No Lifeguard in this Connection Pool”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article