Why bind hibernate SessionFactory to a JNDI resource?

Question

In my current adventure of learning hibernate and setting it up to use an appserver's connection pool, most examples and resources out there point you in the direction of binding the SessionFactory to a JNDI resource in your appserver in the process.

I wondering what the benefit of this is? Since the you can access a the connection pool with out doing this.

Declass

Answer 1

The same reason you'd use JNDI for anything, I'd say - moving the configuration out of the application, into the deployment environment.

With JNDI, you basically say "this application needs a SessionFactory; and its name shall be X" and you're happy as long as the application server has a SessionFactory called X configured. This kind of externalization has several appealing benefits:

1. You can use wildly different configurations on different machines (production and QA use Oracle, developers use HSQL, ...).

2. You don't need to make your build process aware of configurations (no more ant war_for_qa or screwing around with Maven profiles).

3. You're not tempted to check configurations into version control, and so your live database password won't be known to every temp, intern, consultant or ex-employee who's ever had (or will have!) access to the repository.

4. Your installation/configuration instructions won't include items like "to configure the database login, edit the file foo.properties in the WAR file" which will inevitably result in configurations being overwritten on the production server at the worst possible moment because a sysadmin who's been working all weekend happened to deploy a non-edited WAR because the coffee ran out on Sunday afternoon.

JNDI just happens to be the "standard" way of doing this externalization in Java, which means that new devs/admins won't need two days of training to learn the quirks of your own, home-brewn configuration system which really is quite clever but has this weird bug no one wants to delve into because it's really weird and anywho it has a pretty simple workaround, &c.

Related: What is the purpose of JNDI?

Hindustani

@Hindustani That was what I figured. I was just not sure if I was missing something else. We are using JNDI for our connection pool, so I guess I was wondering if there was an added benefit to moving the SessionFactory to the appserver as well. In our case I do not think there would be, since the configuration for it is exactly the same across all our servers. By the way, your answer is probably the best answer I have seen in a while as far as being very clear and informative. – Declass

Am I right that the main purpose is to make it available across multiple applications deployed on the same server? If this is the case a big advantage is the shared 2nd level cache of the SF. Our SF resides within a @Singleton @Startup @EJB since we have only a single application deployed. – Ceric

@djmj, sounds feasible but I honestly don't know how app servers handle this, since I've never run into an app using an externally defined Hibernate/JPA setup - most apps seem to be deployed the way you describe. I can imagine it having implications on stability, security etc and therefore not use a shared 2nd level cache. – Hindustani