Claude Moore wrote:Which version of the driver are you using ? Maybe, it's an outdated one, so that autoregistering of the driver doesn't take place. Are you sure you are loading the correct driver class ?
I tried with:
it worked, bu I also got a warning:
"Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary."
Tim Holloway wrote:
Claude Moore wrote:From JDBC 4.0, if I'm not wrong, JDBC drivers are automatically registered when present in classpath;
You are not wrong. There's a special line in the Manifest file in the JDBC driver jar that is detected to register the driver class. Class.forName is extremely obsolete at this point. It's harmless, but unnecessary.
The registerDriver method is supposed to be called by the driver itself when this condition exists, not part of user-written code.
Claude Moore wrote:I tried this:
And it worked without problems. MySql Server release is 5.6
Claude Moore wrote:It may silly to ask you this: have you tried using
It should do treat special characters for you.
Ron McLeod wrote:Is the regex [^A-Za-z|[0-9]*] correct? I've never seen a vertical-bar/pipe character in a character class (I'm not a regex expert though). Why not just define a class simply composed of the three ranges A-Z, a-z, and 0-9 ?
Your code with the expression [^A-Za-z0-9]:
running on Windows 10 with Java 8 produces this result:
Tim Holloway wrote:
Because, as I said, starting an entire connection pool is even more work than starting a connection from scratch. And if we assume that the point of a micro-service is to be lightweight, that would mean that it's better to be provided with a ready-made source of connections than have to repeatedly create and destroy the whole shebang.
Tim Holloway wrote:I'm not sure what you're asking. But a Connection Pool is a waste of resources for a single-threaded app. Pools are more suited for multi-threaded and/or multi-user apps where you don't want a given task to hang on to Connections, and you don't want to create a Connection from the ground up every time a task needs one.
My objections to the sample code you pointed to initially were based on the sloppiness of the design and code, not its utility. Both it and the H2 sample are merely trying to show how to set up a Connection Pool and use it. They're illustrative, not real-world uses. In the real world there'd be a lot more going on. And yes, normally you create the pool(s) at or near start-up and would only destroy them at shutdown. Because creating a Connection Pool is at least as much overhead as creating a raw connection, and depending on whether it builds a minimum pool in advance, potentially much more. Pools only pay for themselves when you're asking for Connections multiple times and releasing them in between.
Tim Holloway wrote:
Mike London wrote:
Aside from the Class.forName, the code is quite similar to that on the H2 site itself:
Well, yes. It's not exactly rocket science there. The difference is that on the H2 site, they're setting up, running an example, and shutting down. They didn't write code that leaks previous instances of a pool only to create a new pool instance every time you ask for it.
Tim Holloway wrote:Your first warning should have been this line:
It's probably been 15 years now since that was necessary. This person obviously isn't as clever as he thinks he is.
Secondly, it looks like the getConnectionPool method was attempting to return a singleton object. It obviously fails to do so. And to add insult to injury, it's not even in its own factory class - it's lumped in with the application code.
Moral of story: Not everything you find on the Internet is gold. No matter how high up in a Google search it might appear.