On Mar 12, 2006, at 10:06 PM, Allen Gilliland wrote:
Speaking more specifically about applying transaction demarcation
at points in the dispatch layer ... I think I still see this as
allowing persistence logic into the business/presentation layer.
The other reason why this makes me nervous is that I think it
creates some potential for two situations ...
1. catching a persistence exception too late. if the transaction
demarcation doesn't actually commit the transaction data until a
while after the app thinks the data has been written then we may
end up putting ourselves in a situation where we catch an exception
after we have already commited some of the response and are no
longer in a situation where we can respond appropriately. This
seems especially true if we consider each request/response cycle as
a single transaction and only flush/commit the data in a filter as
we exit the app.
2. commiting data changes we don't want, specifically users being
bad with their templates. I suppose our wrapper objects may take
care of the potential problem with users making changes to their
data that we don't want, but there may also be an issue of app code
doing the same thing. It has always seemed ideal to me to only
commit changes specifically when needed. If a filter simply commits
data at the end of the request/response cycle there is no guarantee
that someone hasn't modified an object that is not meant to be
saved back to the database.
Yes, the persistence filter should never do a commit. It should do a
rollback and I thought it did that, but it appears that right now it
just closes the connection and Hibernate session via call to
Roller.release() -- effectively the same thing, but I'd rather see an
explicit rollback.
- Dave
