You Don't Need To Think About Transactions If:
- Your application has no persistence and do not interact with transactional resources like messaging, legacy interfaces etc.
- The application is used only by one user in sequential way in a single thread.
- It only reads the data and no one writes or if it only writes the data, and no one reads :-).
- The access to persistent storage, backend resources is performed in one (business) method.
- 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.
- 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 #