Posty

Data consistency and performance in web applciation

Obraz
Introduction In this article we are going to look at various implementations of bank transfer in a web applciation API taking into consideration data consistency and performance.  Technologies and software I am using in examples below are: PostgreSQL, Java 17, JDBC, Spark Java, JMeter, Postman, IntelliJ Approach 1 - plain SQLs We start by creating a following piece of code to perform a bank transfer: In terms of DB operations we can write it in following way: SELECT source account balance SELECT target account balance UPDATE source account balance UPDATE target account balance We can test how will it behave when there are multiple users performing transfers concurrently. In my case I am going to place this code in a simple Jetty server and use JMeter to simulate the traffic.  Here is the JMeter load testing thread config (please note that same user on each iteration is unchecked): with web server request config: and payload: As you can see we will perform 100 POST request

PostgreSQL transactions behind the scenes - MVCC, locks, isolation levels

Obraz
Content MVCC Xmin and Xmax VACUUM command.  Locks Transaction isolation levels Used tools: PostgreSQL setup with Docker:  https://hub.docker.com/_/postgres pgAdmin:  https://www.pgadmin.org/ MVCC PostgreSQL uses multiversion concurrency control (MVCC) architecture to implement transactions with proper isolation levels. MVCC makes concurrent access possible and safe by maintaining several versions of a row. Row is enriched with additional metadata which is xmin and xmax. Lets take a look at the example: Xmin and xmax I will insert a new row into the table: We can do a standard select: With followig result: Nothing unexpected. But lets see the result of SELECT that explicitly mentions xmin and xmax columns:   We can now see two new columns in the result: These columns were not added by me when creating the table. They are handled by MVCC mechanism in PostgreSQL. As the official documentation states: xmin - The identity (transaction ID) of the inserting transa

Spring Data 2# - support for Couchbase

In this article we will have a look at how NoSQL Couchbase database is supported in Spring, especialy in Spring Data module. Couchbase is a document oriented NoSQL database which has gained a lot of popularity in the last few years. The main reason for that may be its specialization in a low latency data management for large scale web applications. Couchbase introduction Couchbase is a NoSQL document database which is a subset of a key-value stores. It is designed to store and retrieve data in JSON format. Each separate JSON item stored in the database is called a document. Couchbase does not force any specific schema on the data that is stored. It is often said that in NoSQL databases any schema specific constraints are moved from the database layer to the application layer . It often provides a better ways to develop a software with dynamic data structure changes since changes in the documents structure do not break any database constraints or schema. In this case you can update

Hibernate 3# - Session API

Hibernate's Session is the interface that provides API for Java application to interact with persistence layer. It introduces CRUD methods to operate on entities. It also contains methods used to handle transactions. We can say, that Session  is the core interface in the Hibernate library. We will have a look at the core features of Session and how it is handled in Spring framework. Entity Management You will often see additional layers of abstraction over Session interface (like in Spring, which is discussed later). However, in this part of the article I will show some basic examples of using  Session object directly with regard to operations on entities. Entity is a domain model class. Its instance represents in the Java world a database row. As an entity example we will use following class: As you can see we are using multiple annotations which are needed by Hibernate to properly map the entity instance to a database row and vice versa. This annotations are @

Hibernate 2# - physical vs logical transactions

There are often some confusions in the regard of using 'transaction' term, especially when talking about ORM solutions like Hibernate. Sometimes transaction can have a different meaning depending on the context. It needs to be understood in order to be able to prevent any data anomalies during web development. We will have a look on what are the differences between physical and logical transactions.  Physical transaction Physical transaction is the actual transaction that takes place on the database level. It means that the beginning of the physical transaction is when actual transaction on the database level is started. The end of the physical transaction takes place when this transaction is commited or rollbacked on the database level. Atomicity of operations made during physical transaction is guarded by database itself. Logical transaction Logical transactions on the other hand are those handled on the the application side, for example Spring application. Logica