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).
Posted at 12:27PM Dec 19, 2006 by Adam Bien,
Comments[1]
| Views/Hits: 130
NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.

Are you saying you can get a JDBC Connection that is not part of a Transaction?

What I was trying to say re PersistenceContext is that for a long time we have been using Client Server tools (PowerBuilder, Developer2000, Delphi etc) and they didn't have or require a 'PersistenceContext'. For me, the same goes with JDBC used in a similar client/server fashion (with flat results rather than an Object Graph).

That all said, you may be on a different track here... but I don't follow what you are saying I'm afraid.