You Don't Need To Think About Transactions If:

  1. Your application has no persistence and do not interact with transactional resources like messaging, legacy interfaces etc.
  2. The application is used only by one user in sequential way in a single thread.
  3. It only reads the data and no one writes or if it only writes the data, and no one reads :-).
  4. The access to persistent storage, backend resources is performed in one (business) method.
  5. You don't need the "Unit Of Work" abstraction. So it is no problem if the application dies between method invocations and the data is partly processed.
  6. It's ok, if other applications, users etc. see the unfinished (uncommitted) activities in their applications.

You know such an application? :-). I hear from time time statements like: "This is just a report - so I don't need transactions - I'm only reading the data". In this particular case you would access the database without a defined transaction and especially isolation - so you will basically see a snapshot of the database (especially uncommitted changes).

Even if you totally ignore the transactions - you will still get the "Green Bar" in most cases. This is probably the reason, why transactions are often in fact ignored ...until the production :-).


Posted by vpetreski on June 30, 2008 at 04:41 PM CEST #

Not sure what database you're using but with Oracle (and I suspect the other major players) you wouldn't see uncommitted changes. That would break any sort of consistency rules. Oracle only shows committed changes. So in the case of Oracle...why do I need transactions to run a read-only report again?

Posted by Jason Kratz on June 30, 2008 at 06:43 PM CEST #


if you do not configure your DataSource, you can not even rely on a certain level of consistency (its dependent on the database settings then). Btw. it is not very uncommon to run database in the "UNCOMMITTED_READ" mode... Furthermore, look at the link before (vpetreski).

If Oracle start a tx for you - it's fine. But it could even start more than one (e.g. for every JDBC statement). Then your whole report wouldn't be coherent / consistent - except you can run the whole report with one SQL-statement...:-).

Posted by Adam Bien on July 01, 2008 at 03:58 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments