Java O/R layer for SQL server?

Question

I've got a java server (not web based, more like a big, many-threaded standalone application) that needs to talk to a MS SQL Server database.

I just worked on a different project that ported a home-grown O/R layer from oracle to SQL Server, and it ran into significant problems because of too many oracle assumptions (locking, mostly). So What O/R layer should I use?

Edit: I have heard of Hibernate, but everything else is useful! Specifically though, do any of these APIs/frameworks help with the peculiar shortcomings of SQL Servers locking strategy in a multi-threaded environment?

Answer 1

Hibernate is the usual choice. Besides that you can take a look at Oracle TopLink, iBatis, whatever suites you best.

Answer 2

I have also used BEA Kodo with Microsoft SQL Server (back when it was Solarmetric Kodo). At the time, it was far more feature rich than Hibernate and any JDO implementation. That's no longer the case, though it still has a number of unique performance/scalability features.

Hibernate is the most popular one available today. My personal favorite is TopLink.

The key standards you want to look for are EJB3, Java Persistance API (JPA), and Java Data Objects (JDO). JPA is probably the most important of the bunch as its easier to use and is meant as a common API for using Hibernate, JDO, Toplink, EJB3, etc.

Answer 3

I've used Hibernate and iBATIS. Choosing one over the other depends upon the situation.

Hibernate:

• is much pickier about database schema
• generates most of the sql for you
• more features
• more complex

iBATIS:

• works better when you want to work with existing schema
• requires you to write your own sql
• easier to learn

They both work well with SQL Server and handle multi threading.

Answer 4

Hibernate is good. But there are different flavors of Hibernate implementation. I suggest Hibernate 3.x (3.2?) with JPA. I also usually use Spring 2.5 as the framework for the business logic. Hibernate and Spring work especially well together, because they can share name resolving scopes to a degree, which lesses the confusion on how to accesses O/R objects.

Answer 5

I suggest Cayenne.It supports a lots of databases. It is open source,too. But there is no so much documents. You can use cayenne with struts.