What problems can arise when mixing JPA with plain-JDBC dao implementations?

Question

We have two teams who want to access the same database using different technologies. One uses JPA (Hibernate, to be specific). The other uses plain JDBC.

I've been asked to compile a list of concerns assuming that each team uses the default configuration and/or "best practices" of each technology.

This is a new database, so imagine that the schema is being designed solely by the JPA team, or solely by the JDBC team, and then they both go about trying to access it.

Can you please share your experiences?

UPDATE: I'm not asking for opinions here. I don't care whether JPA or JDBC is "better". I am asking for an objective list of interoperability concerns when mixing the two technologies.

---

Here is an example of what I'm looking for:

Scenario: A user reads a row, modifies it in memory, and saves it back to the database.

• If JPA uses optimistic locking by adding a version column to each table.
• When the transaction is committed, JPA checks if the version changed between the time that the row was read and the time it was updated. If the version changed, it throws an exception. If not, it allows the commit to continue.
• If the JDBC implementation uses table locks (a.k.a. pessimistic locking), they use SELECT ... FOR UPDATE to prevent concurrent updates.

• Imagine what happens if the JDBC implementation is not aware of the JPA convention and does not update version on commit:

  1. JPA reads a row using SELECT and sees version equal to 1.
  2. JDBC reads a row using SELECT ... FOR UPDATE.
  3. JDBC updates the row (committing its transaction) without incrementing version.
  4. JPA tries updating the row. The commit goes through because version is still equal to 1.
  5. JPA (step 4) just clobbered the update of JDBC (step 3).

Lesson learned: The JDBC implementation needs to know to update the version column.

Answer 1

Building my own list while waiting for other people to answer:

1. JPA uses optimistic-locking by default. This requires adding a version column and incrementing it each time the row is updated. JDBC would have to do the same.
2. Divergent DAO layers are more likely to end up with a divergent model. Meaning, any time the JPA mapping configuration is changed, the corresponding JDBC code might break silently.
3. If JPA uses cascading rules to propagate updates or deletes. JDBC would dhave to do the same.
4. If JPA @Id @GeneratedValue(strategy=GenerationType.SEQUENCE) is used, it creates and uses a sequence table (e.g. hibernate_sequence). JDBC would have to do the same.
5. JDBC would need to support JPA class inheritance tables.
6. If JPA drives schema evolution, the JDBC implementation would need to add support for its conventions/features. On the other hand, if JDBC drives schema evolution then we would need to disable JPA features that impact the schema.
7. Can't use JPA 2nd-level cache if data is modified outside of JPA (courtesy of crizzis)