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.

A recipe for success

When it comes to database programming you shouldn’t ever remain untrained. Constantly learning is your best weapon, there’s no other way.

For this I came up with my own data knowledge stack:

You should always master the bottom layers prior to advancing to upper ones.

So these are the golden rules for taming the data layer:

• The database manual was not only meant for Database Administrators

  If you are doing any database related task than reading your current database manual is not optional. You should be familiar with both the SQL standard and your database specific traits. Break free from the SQL-92 mindset. Don’t let the portability fear make you reject highly effective database specific features. It’s more common to end up with a sluggish database layer than to port an already running system to a new database solution.

• Fully read “Patterns of Enterprise Application Architecture“

  I’ll give you a great investment tip. You are 50$ away from understanding the core concepts of any available ORM tool. Martin Fowler‘s book is a must for any enterprise developer. The on-line pattern catalogue is a great teaser.

• Read your ORM documentation

  Some argue that their ORM tool is the root of all evil. Unless you spend your time and read all the available documentation, you are going to have a very hard time taming your ORM data layer. The object to relational mismatch has always been a really complex problem, yet it simplifies the CREATE/UPDATE/DELETE operations of complex object tree structures. The ORM’s optimistic locking feature is a great way of dealing with the lost update problem.

• Pick and mix

  JPA/Hibernate are not a substitute for SQL. You should get the best of JPA and SQL and combine them into one winning solution. Because SQL is unavoidable on any non-trivial application, it’s wise to invest some time (and maybe a license) for using a powerful querying framework. If you fear that database portability is holding you back from using proprietary database querying features than a JPA/QueryDSL combo is a recipe for success.

I'm running an online workshop on the 11th of October about High-Performance SQL.

If you enjoyed this article, I bet you are going to love my Book and Video Courses as well.

Insert details about how the information is going to be processed

DOWNLOAD NOW