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


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


Adding Data To Objects – Another Builder Pattern

While reading up on builders to write these posts, I came across an interesting blog by Per Lundholm which demonstrated another builder pattern that can be used. This solves the problem of having some fields which are optional and others which are mandatory. As it stands, we are treating all fields the same in the builder, and introducing any specific behaviour we want to for optional fields when we construct the object.

Continue reading


Adding Data To Objects – Using Builders for Immutable Data

To make data immutable, it must be set the moment the object is created, i.e. in the constructor. However, as we’ve seen in the introduction post, adding the data into the constructor directly comes with problems of its own – having multiple arguments in any function increases complexity and makes things confusing.

In the previous post, we were introduced to the concept of a builder, and showed how to construct the object we wanted in a way where the resulting code was easy to read and understand.

Is there a way to combine the two concepts above so that we can use a Builder to create an object where the fields cannot change their values? YES!
Continue reading