Hi KARR, DAVID,
This is just a high level view, but if you're not modifying the
database the only thing you should be concerned about is inconsistent
data.
Within a single database request, results will be consistent assuming
you use read-committed isolation. This is true even if you use auto-
commit on your connection. But inconsistencies are possible between
requests. For example, data that you read in one request might be
deleted by the time you read again.
There is increasing overhead (performance degradation) associated with
increasing consistency. The overhead might or might not be significant
for your application.
The JPA specification focuses on optimistic consistency and in most
cases you aren't getting higher levels of consistency than read-
committed anyway.
Craig
On Dec 13, 2009, at 10:13 AM, KARR, DAVID (ATTCINW) wrote:
I'm constructing an application that at the present time and
foreseeable
future, will just be reading from a database (Oracle) and serializing
those results to XML/JSON. It will not be writing or modifying the
database.
I have a Controller layer, and I have a DAO layer. I'm going to
assemble a service layer between those two, but I'm wondering
whether I
should specify transactional semantics in that layer. I can put
"readOnly" on it (using Spring's "Transactional" annotation), or
perhaps
set the transaction attribute to "NOT_SUPPORTED".
I think I'd prefer to have the service layer be transactional, even if
it's only read-only, but I'm wondering what the impact will be either
way. Will this give me overhead I don't need? Will NOT using
transactional semantics possibly create some race condition that might
bite me somehow?
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[email protected]
P.S. A good JDO? O, Gasp!
