adam bien's blog

Java EE Fallacies feedback: Is transactional context not necessary for "traditional" JDBC access? 📎

I got an interesting comment for the post: Fallacy 2: EJBs are too complex, POJOs are easier.
from Rob Bygrave. He mentions:
"...Transaction Isolation levels come into play and the need for a 'Persistence Context' is an ORM specific requirement and not necessary for more traditional JDBC access..."
Which is partly true. If you do not have a transactional JDBC-connection, you will get every time a new and independent ResultSet. So this could become a problem in case your application grows and you are no more the only developer. In that case the changes made in one connection will be not visible in another. So even working with plain ResultSet can cause some inconsistencies, because actions behind a facade are isolated from the DB-perspective which is more a bug than a feature.
You could ensure consistency using some "patterns"/approaches:
  •  In every use action/use case the DB is accessed only once or in read only mode.
  • Or: A ResultSet instance is shared in a common context and reused in one logical action (method)
  • Or: The transactions are sorted (you read first, then write)
  • Or: You are using a JTA-DataSource and not DTOs.
Working only with JDBC works fine, but the transformation between ResultSet and Data Transfer Objects can cause additional challenges. In that case you will create new copies of the same row in a logical transaction over and over again. It is not a problem in "one man show projects", but in bigger teams it can lead to inconsistencies.
Of course you could build a transactional cache, or just use JPA :-).
Even plain JDBC-access can become a challenge in bigger (amount of developers) projects... For master-data management, simple CRUD use cases etc. JDBC works well enough. JDBC 4.0 is even better - and from my perspective, it could kill some proprietary persistence frameworks, because of simplicity, power and ease of deployment (it is shipped with JDK 1.6).