Mongodb, java, audit, log, howto technologies

The database query log could be a crucial part of a database restoring process required after data corruption caused by either an illegal update operation or a damage of database files. The main task here is to find the right format for storing the queries.

Java, spring technologies

This article is devoted to very popular framework Spring. It’s very necessary theme for beginners in Java, because Spring is widespread technology.
First of all let's consider wiring - dynamical assembling of separated beans, most important part of Spring framework technology. It's important to keep in mind, that a good understanding of fundamental things is a irreplaceable skill for really cool programmer.

Grails, jackson, json technologies

Optimizing Web application request processing time is an important stage of quality product development. While doing this part of the work on one of our products we noticed that the huge bottleneck was buried inside built-in JSON support in Grails. The problem was that built-in JSON parser that comes with Grails is surprisingly slow. Thats why we considered switching to using Java-based JSON parser instead.

Java, nosql, mongodb, howto technologies

Java driver for MongoDB does not provide any utility classes that could help with building update queries. If you want to create a query to update or increment field values, you usually have to use BasicDBObjectBuilder. This is intuitive approach, but queries defined in such a way are quite hard to read and maintain.

Java, nosql, persistent queue technologies

Recently I had a task to develop the application which will have large work queue and which need to survive the restarts. The application need to be lightweight. After trying several different persistent engines for Java I''ve chosen to stick with Berkley DB Java edition. This persistent engine is pretty lightweight it is fast, optimized for multi-threaded usage and have no problems with reclaiming free space.

As I needed the fast persistent queue at a cost of possible data loss on system crash I've chosen non-transactional API for Berkley DB. With non-transactional API the great speed can be achieved for persistent queue at a price of loss of some data at system crash. The more data you allow to be lost the greater speed of the queue you will have. Though you can opt to sync to disk each operation on the queue and in that case your data loss will be minimal.