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, trishagee.com . My blog is now at trishagee.com/blog .  See you there!
Post a Comment

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.

Comments

  1. Ben Darfler16 May 2013 at 22:22

    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.

    ReplyDelete
  2. Unknown18 May 2013 at 12:13

    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

    ReplyDelete
  3. Hendy18 May 2013 at 20:06

    We use java driver 2.11.1 via our own maintained Morphia fork at http://github.com/soluvas/morphia

    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. :(

    ReplyDelete
  4. Ian Rose18 May 2013 at 21:19

    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: http://stackoverflow.com/questions/4463428/difference-between-getelapsedtime-and-getqtime-in-solr-for-java).

    5. Java 7

    ReplyDelete
  5. Geert Van Damme19 May 2013 at 18:07

    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, ...).

    ReplyDelete
  6. Angelo19 May 2013 at 23:17

    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 https://github.com/angelozerr/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 http://angelozerr.wordpress.com/about/mongo_jee/

    ReplyDelete
  7. Anonymous11 September 2013 at 14:39

    1. Yes
    2. Spring Data + Custom annotation processor (https://github.com/mendlik/spring-data-mongodb-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 http://docs.spring.io/spring-data/mongodb/docs/current/api/org/springframework/data/mongodb/core/MongoOperations.html)
    6. Java 7

    ReplyDelete
  8. Unknown4 January 2014 at 04:26

    This comment has been removed by a blog administrator.

    ReplyDelete

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?

Image
Recently we open sourced the LMAX Disruptor , the key to what makes our exchange so fast.  Why did we open source it?  Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world.  Plus it makes us look dead clever. On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast.  I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand. However I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my  NADD audience. First up - the ring buffer.  Initially I was under the impression the Disruptor was just the ring buffer.  But I've come to realise that while this data structure is at the hea...
Read more

Dissecting the Disruptor: Writing to the ring buffer

Image
This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it's quite long.  But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer.  That's because nothing else needs to access your producer, only you need to know about it.  However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit.  First, your producer has to claim the next slot on the buffer.  Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at...
Read more

Dissecting the Disruptor: How do I read from the ring buffer?

Image
The next in the series of understanding the Disruptor pattern developed at LMAX . After the last post we all understand ring buffers and how awesome they are.  Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor. ConsumerBarriers and Consumers I'm going to approach this slightly backwards, because it's probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer? (OK, I'm starting to regret using Paint/ Gimp .  Although it's an excellent excuse to purchase a graphics tablet if I do continue down this road.  Also UML gurus are probably cursing my name right now.) Your Consumer is the thread that wants to get something off the buffer.  It has access to a ConsumerBarrier , which is created by the RingBuffer and interacts with it on behalf of the Consumer .  While the ring buffer obviously n...
Read more