We Keep Coding

Hibernate OGM with mongodb in an enterprise solution

I wanted to ask you, if you have any experience that Hibernate OGM works as much fine with mongodb, that it could be used in an enterprise solution without any worries. With other words - does this combination work as fine as for example Hibernate ORM with MySQL and is is also that easy to set up? Is it worth to use it - meant the level of afford needed to set it up compared to the level of improvement of the work with the database? Would you prefer another OGM framework or even don't use any? I read about it some time ago, but it was in the early stages of this project and didn't work too well yet. Thanks for advices and experiences.

(Disclaimer: I'm one of the Hibernate OGM authors)
With other words - does this combination work as fine as for example Hibernate ORM with MySQL?
The 4.1 release is the first final we consider to be ready to use in production. The general user experience should be not much different from using the classic Hibernate ORM (which still is what you use under the hood when using Hibernate OGM). Also the MongoDB dialect probably is the one we put most effort in, so it is in good shape.
But as Hibernate OGM is a fairly young project, of course there may be bugs and glitches which need to be ironed out. Feature-wise, there are some things not supported yet (e.g. secondary tables, criteria API, more complex JPA queries), but you either shouldn't really need those in most kinds of applications or there are work-arounds (e.g. native queries).
and is is also that easy to set up?
Yes, absolutely. The set-up is not different from using Hibernate ORM / JPA with an RDBMS. You only use another JPA provider class (HibernateOgmPersistence) and need to set some OGM-specific options (which NoSQL store to use, host name etc.). Check out this blog post which walks you through the set-up. For store-specific settings (e.g. how to store associations in document stores) there is an easy-to-use option system based on annotations and/or a fluent API.
[Is it worth the effort] to set it up compared to the level of improvement of the work with the database?
I don't think there is a general answer to that. In many cases object mappers like Hibernate ORM/OGM are great, in others cases working with plain SQL or NoSQL APIs might be a better option. It depends on your use case and its specific requirements. In general, OxMs work well if there is a defined domain model which you want to persist, navigate its associations etc.
Would you prefer another OGM framework
I'm obviously biased, but let me say that using Hibernate OGM allows you to
benefit from the eco-system existing around JPA/Hibernate, be it integration with other libraries such as Hibernate Validator or Hibernate Search (or your in-house developed Hibernate-based API) or tooling such as modelling tools which emit JPA entities.
work with different NoSQL backends using the same API. So if chances are you need to integrate another NoSQL store (e.g. Neo4j to run graph queries) or an RDMBS, then Hibernate OGM will allow you to do so easily.
I read about it some time ago, but it was in the early stages of this project
Much work has been put into Hibernate OGM over the last year, so my recommendation definitely is to try it out and see in a prototype or spike how it works for your requirements.
If you have any feature requests or questions, please let us know and we'll see what we can do for you.

Use hibernate sessionFactory or JPA entityManager?

I'm working on a project that uses Hibernate 4.1, Spring 3.1, and JPA 2.0, and I want to verify that what I've gleaned from the internet is correct.
I'm trying to decide whether to use a JPA entityManager or the hibernate-specific sessionFactory.
At first I planned to use entityManager and full JPA specifications, so my project would be decoupled from Hibernate, and I could switch it out for something else, say EclipseLink, if the fancy took me or something convinced me later on.
However, it seems the entityManager has some very significant limitations.
My questions:
The only reason I would want to use full JPA specifications and the entityManager is to be able to switch out Hibernate for a different JPA 2.0 compatible ORM relatively easily, right? Are there really no performance / functionality / ease of programming benefits to using the entityManager?
Second, it seems like the hibernate sessionFactory has a lot of benefits over the entityManager. So far I've run into the issue that the entityManager can't perform a batch insert of a list of entities, which I've read the sessionFactory can. I've also read that the sessionFactory can return an auto-generated entity ID automatically, while with the entityManager you need to end the transaction / flush the persistence context to pull the newly generated id.
I liked the idea of my project being relatively decoupled from Hibernate, but I would much rather be able to write efficient database updates from the get-go. So I should switch over to my project being configured for hibernate and the sessionFactory, right?

I would stick to JPA2, like you would use List rather than ArrayList: you favour the interface (or abstract) over the implementation. There are not much difference, apart from HQL knowing "more" stuff than JPQL or exotic feature. Also remember that JPA was made after Hibernate, with Hibernate being the "inspiration" behind JPA.
And for exotic feature: Hibernate Entity Manager wrap an Hibernate Session. If you really need them, you can cast the EntityManager to the Hibernate interface (org.hibernate.jpa.HibernateEntityManager), and use that session. But I'd be lying to you if I say I tried it.
I also commented part of your question:
The only reason I would want to use full JPA specifications and the
entityManager is to be able to switch out Hibernate for a different
JPA 2.0 compatible ORM relatively easily, right? Are there really no
performance / functionality / ease of programming benefits to using
the entityManager?
Switching from Hibernate to EclipseLink does not mean you "only need to swap the jar". The mapping, and annotation parsing, is not the same and you'll encounter problems that will probably discourage you from switching.
You can read my question here for an example of a problem I encountered while using both (it was a maven project with a profile to switch JPA2.1 impl from EclipseLink to Hibernate). I dropped EclipseLink because I could not name the database object (or rather, specify the name of database object) like I wanted.
Second, it seems like the hibernate sessionFactory has a lot of
benefits over the entityManager. So far I've run into the issue that
the entityManager can't perform a batch insert of a list of entities,
which I've read the sessionFactory can. I've also read that the
sessionFactory can return an auto-generated entity ID automatically,
while with the entityManager you need to end the transaction / flush
the persistence context to pull the newly generated id.
This depends on how you generate your entity id. But think about it: you entity is not persisted until the persistence context need to persist it. This is the reason you don't have an id. Flushing it, aka sending an insert query with a generated id, is the only way to do it.
The same apply to session factories.
You might however be able to access a sequence generator from Hibernate, but you can also do that in native SQL with EntityManager.
I liked the idea of my project being relatively decoupled from
Hibernate, but I would much rather be able to write efficient database
updates from the get-go. So I should switch over to my project being
configured for hibernate and the sessionFactory, right?
You can take it as a troll against ORM, but for efficient database update, use plain JDBC (or Spring Jdbc Template). At least you'll know when data will be updated, and you'll be able to better optimize (batch update, etc).

JPA is an interface over Hibernate which is an interface over jdbc so the closer you are to jdbc the more control you get over your queries but further you go from object/relational persistence .
Yes, Hibernate may have some tools that jpa may not provide at this moment (i.e hibernate spatial)
Hibernate is fun and can use JPA annotations for mapping the domain model (if you go the annotations way over the .hbm files) . And the way the #Transactional annotation works in Spring it doesnt matter whether you use hibernate or jpa since you dont need session.open() ... session.beginTranscation ...session.close ...etc ... all this verbose Hibernate code is gone!
There is great documentation on Hibernate and greate books as well. As for JPA I cant say that I found the umber book...

Dynamic JPA Entities in EJB Container

Within a GF EJB container, I am trying to dynamically discover my JPA entity classes using ServiceLoader and add them to the the JPA configuration prior to the container creating the EntityManagerFactory. The problem I am having is finding a way to "intercept" the PersistenceProvider configuration for a specific persistence unit prior to the EMF creation.
I attempted to use Hibernate by extending the HibernatePersistence persistence provider, but have had a couple problems (see Using Hibernate Ejb3Configuration with Container Management). I am open to any suggestions. My requirements are that it must run on the EJB container and utilize JPA for persistence. I would prefer to stay with GF and stay as vendor neutral to all technologies as possible (but would appreciate any suggestions).
Thanks!

I'm not sure if this helps here, but consider to use an OSGi approach instead of plain ServiceLoader.
http://weblogs.java.net/blog/2009/06/14/developing-hybrid-osgi-java-ee-applications-glassfish
(I haven't studied this article fully yet, so I'm not sure if it's of any use here.)

EJB3 with Spring

I have understood that if I use EJB in Spring context, I get all the same benefits as if I was using it in "pure" EJB3 environment, is this true? I have googled but can't find a definitive, clear answer.
For example, let's say I have a session bean that updates some tables in the database and it throws a System Exception. In "pure" EJB3 environment the transaction is rolled back. What if I for example #Autowire this bean using Spring, does Spring take care of the transaction handling same way as does the EJB3 container? Or what? Does it maybe require some specific configuration or is it fully "automatic"?

I have understood that if I use EJB in
Spring context, I get all the same
benefits as if I was using it in
"pure" EJB3 environment, is this true?
You usually use either POJO + Spring or EJB3. I'm a bit confused by what you mean by "EJB in Spring"...
POJO + Spring and EJB3 are quite close now, and have the same facilities when it comes to declarative transaction management.
I don't know all the details about security, but I would say that both technologies are also very similar.
Actually both Spring and EJB3 rely on other specifications. The important ones are: JPA (persistence), JTA (distributed transaction), JMS (messaging), JDBC (data sources). Good support for that exist in the two technology stacks.
Both technologies have become very flexible and you can choose what to use or not. So you can have EJB3 in an app. server and be very light. Or you can use Spring with all modules which is almost as heavy as a full-fledged app. server.
I think the EJB3 model is still a bit richer, with things like remoting, stateful session beans (SFSB), container-managed transactions, and extended persistence context. Plus the possible support of clustering depending on the app. server. But these are advanced features which are use seldom (and IMO require expertise).
See EJB3 vs Spring

spring has many features, one of which is transaction management, which uses a common abstraction accross all different orm implementations (jpa, raw hibernate, jdbc, jdo etc). The default behavior is that in a transactional method, a runtime exception causes a rollback (which is probably what you want), but you can also fine-tune the rollback rules.
However, none of this requires EJB. If you don't use EJBs (stateless, stateful, mdbs), JPA will be enough for that, and the spring jpa support is excellent. In 90% of the cases spring will provide everything you need without EJBs.
EDIT:
read this about Spring EJB integration

You can have Spring handle transactions and roll back accordingly. You have to configure it to do so, but that's also true of EJBs.
Nothing in life is truly "automatic". You have to tell the code what you want sometime.
The real question is: Why do you think you need both EJBs and Spring? Anything you can do with EJBs can be done using POJOs with Spring. What are EJBs buying you here?

I got very good answers with links to articles, and from those I compiled my understanding that yes, the session beans work the same way regardless of if they are used with Spring or without, as long as the beans are defined in the Spring context with <jee:jndi-lookup>. Also found a good, simple article about this: http://java.dzone.com/articles/ejb-30-and-spring-25
However I can't accept just one answer because to me they are all equally good, but none of them exactly in point :) Could be that my question was not clear enough to start with...
(It was suggested that I post this as an answer to my own question)

Spring vs Hibernate

Just trying to get my head round Spring and figuring out how I wire up an Oracle connection in xml config file, and now find out I need yet another framework! - Hibernate, this is soooo frustrating as it feels like I'm getting deeper and deeper into more and more frameworks without actually getting what I need done!
I looked at Hibernate and it seems to do similar things to Spring, bearing in mind I just want to do some SQL inserts in Oracle.
I am reluctant and do not have time to learn 2 frameworks - could I get away with just adopting Hibernate for the simple things I need to do?

...could I get away with just adopting Hibernate for the simple things I need to do?
Yes
Hibernate is for ORM ( object relational mapping ) that is, make your objects persistent to a RDBMS.
Spring goes further. It may be used also as a AOP, Dependency Injector, a Web Application and ORM among other things.
So if you only need ORM, just use Hibernate. Time will come when you need Spring, and you will learn it then.
Here's an architectural view of Spring:
And this is Hibernate:

Spring and Hibernate are totally different frameworks for different problems. Spring is a huge framework with many many features, Hibernate is an O/R bridge.
I would recommend using plain old JDBC in your case ('just some SQL inserts in Oracle').

You could get away with using just spring and spring-JDBC integration. Depending on the complexity of your data-access needs it may be more than enough. The spring Object-relation mapping is also worth looking into if you're going to do a lot of data-access.
The nice thing about spring is that it's a very loosely coupled framework. So you can read up on the bits you use, and forget the rest - even in the runtime.

Spring and Hibernate are really intended to do two different things. Spring is first and foremost an inversion-of-control container and configuration subsystem, while Hibernate is a database binding and lazy loading engine. If you don't want to introduce a bunch of new stuff into your code, stick with Spring and roll your own queries or use iBatis to do much simpler database binding.

If all you want is insert sql for oracle I would stick to a simple JDBC library. All you need is a Connection and maybe some ConnectionPool (maybe c3po). Hibernate and the like are too big/too complicated and IMO inferior. Hibernate incorporates JDBC under the hood but in every measurable way is inferior -- harder to use, not faster, and the queries you have to write or not any easier. It is also a testament to their inferiority because HQL also provides a bypass route so you can enter JDBC queries directly. They provide this (I suspect) because for any complex query you simply can't construct it well in HQL.