MongoDB stores by default all dates with time and timezone. What’s wrong with this approach? There’s definetly something wrong when related stackoverflow thread shows more votes for converting dates to string than keeping them using default BSON datetime with timezone.

Full sources from this post can be found on GitHub.

This article describes how to create Spring Boot application with oauth2 authorization using password grant type. This grant type is appropriate for internal clients which we trust to get username and password from the user, like for example internal web UI or native mobile app.

Embedded Redisson Node is a service where you can execute asynchronous tasks using Redis with Redisson. This library is not bound to Spring whatsoever, so if you want to run your tasks in the Spring context you need to bind it manually. However, using Spring Boot with Devtools you may encounter some class loading problems between Redisson Node and Spring context, what I’ve today. Here is a quick howto what’s this about and how to overcome this problem.

Doing some proofs of concept for the brand new microservices architecture using Spring Boot and Spring Cloud I’ve chosen few backing technologies for tests. To create serious web application we need at least a database, something for messaging and distributed session/cache. The most common choices as always come from Spring-supported technologies and my ones are PostgreSQL and MongoDB as databases (depending on if we need transactional database in the specific service or not), Redis as a distributed memory grid and RabbitMQ for messaging. Now it’d be nice to have everything working transparently under one transaction manager.

Thinking about new application architecture with Spring Cloud with Netflix OSS I’ve stuck on a problem of time you need to wait until the Ribbon client is ready to serve. It looks by default you need to wait 30s before server list is fetched from Eureka server and Ribbon load balancer can be used to route traffic to specific service. This is a pain in dev env because here we frequently need to restart services and test some results again and again. 30s is not an option, so I’ve been looking for decreasing this time what finally turned out to be a difficult thing.

This catching title will be not about distributed hibernate search, but something really close :)

The case I’ve recently solved was a quite different. I have a frontend application that uses hibernate database and hibernate search, and then I needed to add additional application - let’s call it an integration server, which exposes some API webservices for the overall system. Integration server uses the same database as the frontend application, and enables clients to put data to the database using its webservices. Both applications exist on two different physical servers, as well.

In the current project we faced the problem of concurrent changes to database, for the data that should be accessed sequentially. Imagine you have the customer’s bank account where he can withdraw the money. If the customer is not a person, but company, and if he can have multiple users accessing the bank application, without any locks there’s a chance for situation where two or more users depute transfers, that exceed the account balance, but because data is accessed concurrently, they both can make payoff.

This article describes some complementation for Open Session In View pattern for Java/Spring. But first I want to show just my point of view about the pattern itself. Many people consider this as an anti-pattern and tell that it never should be used. I think exactly opposite, and here are some explanations.

If you have a Spring 2 application using MuleESB in 2.x version, and you initialize the mule using SpringXmlConfigurationBuilder, you may notice that this simply doesn’t work in Spring 3 ;)

I’ve recently had a requirement of setting up the application to work in high-availability environment, which among the others involved hardiness for database (mysql) crash. We established with the customer that we want to have a second database server, where the mysql database mirror will be maintained using master-slave mysql replication. In this model the master mysql server takes care of synchronizing records from itself to the slave server, and the slave server is available in fail-scenario for the application in read-only mode.