https://javapro-en.svenruppert.com/authors/franck-pachot/Recent content in Franck Pachot on JAVAPRO InternationalHugoen-USThu, 18 Dec 2025 07:00:01 +0000https://javapro-en.svenruppert.com/no-deadlocks-in-mongodb-atomic-documents-and-retries-with-spring-data-mongodb/Thu, 18 Dec 2025 07:00:01 +0000https://javapro-en.svenruppert.com/no-deadlocks-in-mongodb-atomic-documents-and-retries-with-spring-data-mongodb/<p>Deadlocks are frequent in SQL databases, as normalization and two-phase locking (2PL) require locking multiple tables or rows during DML operations. Numerous use cases share them, and transactions might access data in a different order, resulting in circular waits and deadlocks. While databases can detect them, they can&rsquo;t prevent or resolve deadlocks, as the application determines what is run and in what order. The best the database can do is cancel one statement or transaction, and let the application rollback and retry, which can reduce performance as systems wait several seconds before getting notified. As Oracle Database makes clear in the error log: &ldquo;<em>It is a deadlock due to user error in the design of an application or from issuing incorrect ad-hoc SQL</em>.&rdquo; Most RDBMS use pessimistic locking to avoid conflicts, but deadlocks are unavoidable, and locking can increase latency. For instance, by default, DB2 waits 10 seconds for deadlock detection, SQL Server waits 5 seconds, Oracle waits 3 seconds, and YugabyteDB and PostgreSQL wait 1 second. These delays impact latency, but deadlock prevention remains the application&rsquo;s responsibility. The only way to entirely prevent deadlocks is by avoiding locks altogether, as in MongoDB, which provides lock-free ACID transactions.</p>https://javapro-en.svenruppert.com/java-and-databases-from-sql-to-jpa-and-nosql/Thu, 19 Jun 2025 07:00:02 +0000https://javapro-en.svenruppert.com/java-and-databases-from-sql-to-jpa-and-nosql/<p>Over the past 30 years, Java has significantly changed the way applications interact with databases. In the early days, Java applications typically used a client/server model and a three-tier architecture, where SQL statements were often embedded as string literals within the application. These statements were sent to databases through straightforward interfaces such as JDBC.</p> <p>As programming paradigms shifted towards Object-Oriented Programming (OOP), Java developers began to integrate business logic more seamlessly into data structures. This move represented a shift from purely database-centric models to application-first designs. This transition enabled data abstraction through application programming interfaces (APIs), allowing SQL database tables and rows to be represented as classes and objects within the application. As a result, data sharing and persistence also evolved, moving from strictly normalized relational tables to document-oriented databases that align more closely with object-oriented structures and specific use cases.</p>