PostgreSQL, like many modern RDBMS, offers both MVCC (Multi-Version Concurrency Control) and explicit pesimistic locking for various use cases when you want a custom concurrency control mechanism.
However, PostgreSQL also offers advisory locks which are very convenient to implement application-level concurrency control patterns. In this article, we are going to explain how PostgreSQL advisory locks work and how you should use them.
Continue reading “How do PostgreSQL advisory locks work”
In Concurrency Control theory, there are two ways you can deal with conflicts:
- You can avoid them, by employing a pessimistic locking mechanism (e.g. Read/Write locks, Two-Phase Locking)
- You can allow conflicts to occur, but you need to detect them using an optimistic locking mechanism (e.g. logical clock, MVCC)
Because MVCC (Multi-Version Concurrency Control) is such a prevalent Concurrency Control technique (not only in relational database systems, in this article, I’m going to explain how it works.
Continue reading “How does MVCC (Multi-Version Concurrency Control) work”
Today, one of my Twitter followers sent me the following StackOverflow question, and, while answering it, I realized that it definitely deserves a post of its own.
In this post, I will explain how you can encrypt and decrypt data with Hibernate.
Continue reading “How to encrypt and decrypt data with Hibernate”
All projects I’ve been working on have used database connection pooling and that’s for very good reasons. Sometimes we might forget why we are employing one design pattern or a particular technology, so it’s worth stepping back and reason on it. Every technology or technological decision has both upsides and downsides, and if you can’t see any drawback you need to wonder what you are missing.
The database connection life-cycle
Every database read or write operation requires a connection. So let’s see how database connection flow looks like:
The flow goes like this:
- The application data layer ask the DataSource for a database connection
- The DataSource will use the database Driver to open a database connection
- A database connection is created and a TCP socket is opened
- The application reads/writes to the database
- The connection is no longer required so it is closed
- The socket is closed
You can easily deduce that opening/closing connections are quite an expensive operation. PostgreSQL uses a separate OS process for every client connection, so a high rate of opening/closing connections is going to put a strain on your database management system.
The most obvious reasons for reusing a database connection would be:
- reducing the application and database management system OS I/O overhead for creating/destroying a TCP connection
- reducing JVM object garbage
Continue reading “The anatomy of Connection Pooling”