A beginner’s guide to natural and surrogate database keys
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Types of primary keys
All database tables must have one primary key column. The primary key uniquely identifies a row within a table therefore it’s bound by the following constraints:
- UNIQUE
- NOT NULL
- IMMUTABLE
When choosing a primary key we must take into consideration the following aspects:
- the primary key may be used for joining other tables through a foreign key relationship
- the primary key usually has an associated default index, so the more compact the data type the less space the index will take
- the primary key assignment must ensure uniqueness even in highly concurrent environments
When choosing a primary key generator strategy the options are:
- natural keys, using a column combination that guarantees individual rows uniqueness
- surrogate keys, that are generated independently of the current row data
What I learned at Topconf Bucharest
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
I’ve got back from Topconf Romania 2014, a developer to developer conference that emerged in Tallinn and for the first time this year it was also held in Bucharest.
As an architect, I assumed I’d be after technical speeches but I got really impressed by some management related presentations as well.
Lessons learned
A conference is a great learning experience. New technologies are being advertised and software paradigms get dissected and questioned by both the speakers and the attendees. There were some great ideas I came back with and I’ll share with you as follows:
It’s all about feedback
Feed-back is the tool of wise people. Every action has an associated reaction and the feedback is a reinforcing factor you should never ignore.
Nothing is perfect but feed-back can help you get better. Feed-back is probably the only suitable learning technique in the ever-changing environment of software development.
We inherently use feedback to build better relationships, to shape our personalities or understand a problem space whose function depends on way too many variables to think of any formula that can always give you the right result.
The minimal configuration for testing Hibernate
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
In my previous post I announced my intention of creating a personal Hibernate course. The first thing to start with is a minimal testing configuration.
You only need Hibernate
In a real production environment you won’t use Hibernate alone, as you may integrate it in a Java EE or Spring container. For testing Hibernate features you don’t need a full-blown framework stack, you can simply rely on Hibernate flexible configuration options.
The data knowledge stack
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Concurrency is not for the faint-hearted
We all know concurrency programming is difficult to get it right. That’s why threading tasks are followed by extensive design and code review sessions.
You never assign concurrent issues to inexperienced developers. The problem space is carefully analyzed, a design emerges and the solution is both documented and reviewed.
That’s how threading related tasks are usually addressed. You will naturally choose a higher level abstraction since you don’t want to get tangled up in low-level details. That’s why the java.util.concurrent is usually better (unless you build a High Frequency Trading system) than hand-made producer/consumer Java 1.2 style thread-safe structures.
Is database programming any different?
In a database system, the data is spread across various structures (SQL tables or NoSQL collections) and multiple users may select/insert/update/delete whatever they choose to. From a concurrency point of view, this is a very challenging task and it’s not just the database system developer’s problem. It’s our problem as well.
A typical RDBMS data layer requires you to master various technologies and your solution is only as strong as your team’s weakest spot.
The simple scalability equation
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Queuing Theory
The queueing theory allows us to predict queue lengths and waiting times, which is of paramount importance for capacity planning. For an architect, this is a very handy tool since queues are not just the appanage of messaging systems.
To avoid system over loading we use throttling. Whenever the number of incoming requests surpasses the available resources, we basically have two options:
- discarding all overflowing traffic, therefore decreasing availability
- queuing requests and wait (for as long as a time out threshold) for busy resources to become available
This behavior applies to thread-per-request web servers, batch processors or connection pools.
The simple scalability equation @vlad_mihalceahttps://t.co/ajur9yg6qB pic.twitter.com/GOB9GffSBN
— Java (@java) January 30, 2019
What’s in it for us?
Agner Krarup Erlang is the father of queuing theory and traffic engineering, being the first to postulate the mathematical models required to provisioning telecommunication networks.
Erlang formulas are modeled for M/M/k queue models, meaning the system is characterized by:
- the arrival rate (λ) following a Poisson distribution
- the service times following an exponential distribution
- FIFO request queuing
The Erlang formulas give us the servicing probability for:
This is not strictly applicable to thread pools, as requests are not fairly serviced and servicing times not always follow an exponential distribution.
A general purpose formula, applicable to any stable system (a system where the arrival rate is not greater than the departure rate) is Little’s Law.
Time to break free from the SQL-92 mindset
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Are you stuck in the 90s?
If you are only using the SQL-92 language reference, then you are overlooking so many great features like:
Some test data
In my previous article I imported some CSV Dropwizard metrics into PostgreSQL for further analysis.
How to import CSV data into PostgreSQL
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
Many database servers support CSV data transfers and this post will show one way you can import CSV files to PostgreSQL.
SQL aggregation rocks!
My previous post demonstrated FlexyPool metrics capabilities and all connection related statistics were exported in CSV format.
When it comes to aggregation tabular data SQL is at its best. If your database engine supports SQL:2003 windows functions you should definitely make use of this great feature.
Professional connection pool sizing with FlexyPool
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
I previously wrote about the benefits of connection pooling and why monitoring it is of crucial importance. This post will demonstrate how FlexyPool can assist you in finding the right size for your connection pools.
Know your connection pool
The first step is to know your connection pool settings. My current application uses XA transactions, therefore we use Bitronix transaction manager, which comes with its own connection pooling solution.
Accord to the Bitronix connection pool documentation we need to use the following settings:
- minPoolSize: the initial connection pool size
- maxPoolSize: the maximum size the connection pool can grow to
- maxIdleTime: the maximum time a connection can remain idle before being destroyed
- acquisitionTimeout: the maximum time a connection request can wait before throwing a timeout. The default value of 30s is way too much for our QoS
FlexyPool, reactive connection pooling
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Wouldn’t that be just awesome?
Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, or Play Framework.
So, enjoy spending your time on the things you love rather than fixing performance issues in your production system on a Saturday night!
Introduction
When I started working on enterprise projects we were using J2EE and the pooling data source was provided by the application server.
Scaling up meant buying more powerful hardware to support the increasing request demand. The vertical scaling meant that for supporting more requests, we would have to increase the connection pool size accordingly.
Horizontal scaling
Our recent architectures shifted from scaling up to scaling out. So instead of having one big machine hosting all our enterprise services, we now have a distributed service network.
This has numerous advantages:
- Each JVM is tuned according to the hosted service intrinsic behaviour. Web nodes employ the concurrent low pause collector, while batch services use the throughput collector
- Deploying a batch service doesn’t affect the front services
- If one service goes down it won’t affect the rest
