This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, . My blog is now at .  See you there!

How are you using MongoDB with Java?

So, like one of my presentations, I have a question for you.  Actually, I have more than one question for you.  I'm not going to bother with survey monkey or whatever, I want to share the answers so please, answers in the comments:
  1. Are you using the Java driver for MongoDB in your application?
  2. Are you using the Java driver directly, or are you using a third party library like Morphia, Spring Data, the Scala driver, your own abstraction layer, etc?
  3. If you're using a third party library, why did you choose that over using the Java driver directly?
  4. If you're using the Java driver directly, what do you like about it? 
  5. If you're using the Java driver directly, are there any areas that give you pain?  Areas for improvement?
  6. Which version of Java are you using?
Feel free to leave additional information if you have it.  And this is a public blog, so if you're really mean I'll just delete your comment.  So there.


  1. 1) Yes
    2) Casbah
    3) Because Scala is a superior language ;-)
    6) 1.6 but only because I'm lazy. Please, give me a reason to upgrade.

  2. 1. Yes
    2. Own abstraction level over Java driver
    3. Much more friendly to use with additional useful functionality
    4. -
    5. Initialisation phase (infinity loop, driver waiting when at least one mongo host will be accessible)
    6. 2.10.1 Java driver version, 1.6/1.7 Java version

  3. We use java driver 2.11.1 via our own maintained Morphia fork at

    Indeed the mapping is painful.

    We also use JasperReports and our own JasperReports mongoDB connector, since JasperSoft version doesnt work with mongodb 2.4.

    And yes reporting is also painful. :(

  4. 1. Yes

    2. In most core code, our own abstraction layer, but directly in some peripheral places.

    3. The API isn't bad, but an abstraction layer lets us add hooks for things like statistics, measurements, permissions, etc. I'll also note that manipulating JSON-like structures (and thus most of the MongoDB API) is significantly more cumbersome in most statically-typed languages like Java where you can't have collections of heterogeneous types. In something like Javascript or Python this is _much_ nicer and thus I would be more likely (at least in this respect) to use the driver directly.

    4. It easy to trace writes because (with the appropriate writeconcern) these happen synchronously: you make the call, and when it returns the operation has completed. This makes timing measurements and the like easy. Reads, however, are a real hassle. How long is your app spending waiting on Mongo to complete read requests? That's very hard to measure since (in many cases) you are reading from a cursor which hides 'getmore' calls. Although this is a convenient programming model its hard to measure. I'd love if a cursor object exposed methods to query how long it has (so far) spent waiting on responses from Mongo. Even better would be to separate out total time waiting (including network time) and the time Mongo actually spent working (Solr does this, see:

    5. Java 7

  5. 2 Also our own (very small) abstraction layer. In fact, the only thing it does is translate a DBName (String) to an actual Mongo instance.
    Plus a few convenience methods (for Dates, logging, ...).

  6. In my case I have studied how to use Mongo (with Java Driver) in WebApp Application with JAX-RS. All samples that I have found was based on Pojo Mapper. But I told me "why using Pojo Mapper although Mongo manages their data with BSON representation"?

    That's why I have decided to create Mongo JEE which gives you some helpfull classes to use the Mongo structure (DBCursor, DBObject, etc) and not Pojo in JEE context (Servlet, JAX-RS).

    I have explained step by step my study and the benefit with Mongo JEE in my articles

  7. 1. Yes
    2. Spring Data + Custom annotation processor ( for replacing text queries with metamodel
    3. Spring Data + Custom annotation processor is really easy to use. It provides great mapping mechanism, and contains really handy DAO (MongoOperation.class
    6. Java 7

  8. This comment has been removed by a blog administrator.


Post a Comment

Comments have been disabled since this blog is no longer active.

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Dissecting the Disruptor: Writing to the ring buffer

Dissecting the Disruptor: Demystifying Memory Barriers