JDBC, C3P0 and connection pooling

This week we hit a strange issue at work which required us to understand some of the interactions between MySQL, JDBC (the API for a Java application to connect to a database) and C3P0 (a common connection pooling library). This sort of thing is something I’ve never really looked into, so I thought it was prime time to do a bit of background reading (and writing!). Below I’ve summarised my understanding of how connection pooling works for applications in general.
Continue reading


Networking – Security

SSL (now called TLS)

At the end of the last post, we were at the stage where a client and server could communicate via TCP once they had performed the necessary handshake. The problem with this is that anyone can eavesdrop on this connection, and intercept the messages being sent across. That may be absolutely fine in some cases, but where the data is more sensitive we probably want some additional confidence not only that we are actually communicating with our intended recipient, but that only that recipient will be able to understand our messages.

This is where TLS (Transport Layer Security) comes in. (Aside: TLS Used to be called SSL (Secure Sockets Layer)). This involves yet another handshake (you’ve got to be really good friends before you get to hear each other’s secrets!), which is done in the following way:

  1. The client sends the server an initial “hello” message, which tells the server which encoding it can handle
  2. The server responds with its own “hello” message, which contains a few different bits of information for the client:
    • Which encodings it would like to use (CipherSuite)
    • A session ID – This can be used in future by the client to restart the session, so that the handshake doesn’t need to be repeated
    • A server certificate
    • Public key of the public/private pair (for encoding/decoding)
    • The signature of the server, so the client knows they’re talking to the right one
  3. The client verifies the server certificate
  4. Diffie-Hellman key exchange (more on this later)
  5. The client (optionally) sends a client certificate
  6. The server verifies that certificate
  7. The client sends a FINISHED message. This is the first message that is encrypted using the shared key.
  8. The server sends a FINISHED message. Once both the server and client have decrypted each others FINISHED messages, we know they can understand each other
  9. Finally, messages can be exchanged securely! Yay!

Diffie-Hellman Key Exchange

This is a method where two (or more) individuals can collaboratively create a shared secret despite sharing information in the public sphere. It’s actually pretty smart, here’s how it works:
Suppose Harry and Ron are trying to communicate securely. They both come up with a public key which they share, e.g. g = 2, p = 5. Next, they each come up with their own secret integer a, and send g^a \mod p to the other. So
Harry: secret integer 3, send 2^3 \mod 5 = 8 \mod 5 = 3 to Ron
Ron: secret integer 4, send 2^4 \mod 5 = 16 \mod 5 = 1 to Harry

Harry and Ron then take the number they were sent (b), and use that number with their secret integer (a) to calculate b^a \mod p, i.e.
Harry: receives 1 from Ron, calculates 1^3 \mod 5 = 1 \mod 5 = 1
Ron: receives 3 from Harry, calculates 3^4 \mod 5 = 81 \mod 5 = 1

This result is the same! And always will be – i.e. this is their shared secret. Now they can use this to encrypt/decrypt messages to and from one another using it.

Let’s look at what would happen if Draco tried to intercept the messages:
He would know the public key – g = 2, p = 5, and the result of the first calculation, but neither of the secret integers. Therefore, to get to the result of 1 like the other two, he’d have to look at the numbers sent (3 and 1) and try and work out at least one of the secret integers, to then use it in step 2:
1 = 2^x \mod 5
3 = 2^y \mod 5

Since we’re using small numbers in this example, finding x and y is a fairly simple task, but in practice with much larger primes this becomes a much more significant ask, even for the most powerful computers. He’s much better off trying Fred and George’s Extendable Ears for eavesdropping…


Networking – The Lower Layers of the OSI Model

There’s a lot of things that I’ve still got no idea about in this vast technical world – and one of those things is how things work under the hood. When faced with the question “What actually happens when you type in your browser?” I found myself staring blank faced at the person who posed the question, which prompted a conversation about networking and how data gets transmitted from one place to another. I’ve attempted to summarise some of the concepts discussed in that conversation in this post.

Continue reading


I Am Not A Feature Machine

It’s easy to have a bias of thinking that you and the company you work for have different interests, and there is a trade off between being selfish or doing what the company wants. With this mindset, self improvement feels like something that shouldn’t be done on the company’s dime, or should at least be regulated, so that the employee and the employer can both strike a compromise where both interests are met to some degree. In other words, you think of your role at work to be that of a “Feature Machine”.

Continue reading


How to Beat Blue Monday – Apply The Toyota/Improvement Kata!

The title of this blog sounds more like a self help blog than a technical one! However, I actually find it really interesting to see how models and processes we apply at work can help in many different walks of life. The Toyota Kata is one such concept which actually makes a lot of sense to apply to various different situations.

For those who have not heard of the Toyota Kata, it is a pattern for continuous improvement. It works by allowing yourself to focus on an immediate goal to make incremental steps towards a larger objective.
Continue reading


Continuous Deployment – A Whole New World

At my previous company, I’d experienced release cycles of 1 to 3 months, and release day was usually pretty stressful, especially when a big change was going in! We had various branching strategies to make sure only the code we expected to be released would go in. (Whilst in theory it should be fairly simple because no new code should be committed after taking the release cut, in practice, there was always last minute changes going in and I remember keeping these branches up to date, or merging code between master and the release branch sometimes turned into an absolute nightmare.)

Continue reading



It’s been a while since I’ve written a post on here – and a lot has happened in that time! I’ve started working at another company – a much smaller place with a greater focus on technology and culture, and I’m loving it so far! I’ve learnt a huge deal even in the short time (one month) that I’ve been there, and had many interesting conversations with people.

I do need to start writing again, as I’m worried the huge amount of stuff I’ve learnt will very rapidly fall out of my head, so here’s the first post of a series of random musings based on interesting conversations I’m having or facts I’m picking up along the way. This one’s on a conversation I had this week about immutability.

Continue reading