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.
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).
Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition
airhacks.fm the podcast:
Stay in touch: airhacks.news.