a couple more comments inline ...
Anil Gangolli wrote:
Inlining again. Sorry.
*snip*
I can change it to catch a greater scope of exceptions, but I believe
Hibernate wraps all of its exceptions in some version of the
HibernateException, so I imagine this should be fine.
The concern is that other calls made, not just Hibernate work, in the
"...do some work" sections can throw different runtime exceptions and
errors between the two points.
that makes sense. i'll change it to catch all Throwables.
*snip*
(3) Concern/question: With this scoping of commit() we might see
increased likelihood of weird behavior in views immediately after
commits on some databases. In particular (a) in some databases they
might not yet reflect committed changes of the transaction just
committed in other transactions and (b) we might hit
LazyInitializationExceptions . For some background on the latter
issue see the Hibernate reference manual Section 11.1 and 11.1.1, and
http://www.hibernate.org/43.html, particularly the FAQ 'Can I commit
the transaction before rendering the view?' The latter problem could
be addressed by ensuring we create a second transaction for the view
before any objects in the session get referenced by the view code;
maybe this is what you are already doing, but it wasn't clear this is
happening. Is it already dealt with?
This sounds more like a Hibernate issue than an architecture issue to
me. The fact is that this issue will exist in any implementation
because thread1 could have just committed some changes a split second
after thread2 read those same objects for use. Obviously we don't
want to be getting LazyInitializationExceptions, but again, that is a
Hibernate issue, not an architecture issue.
Hibernate demands that all operations happen within a transaction, so
if you peek at the code you will see that all XXXManager methods begin
with a call to session.beginTransaction().
No it's not a Hibernate issue. However, if all of our operations
forward to views which go back to the manager methods as you indicate to
repopulate a session, then we're probably fine.
I still think this is somewhat related to the way Hibernate works and is
not necessarily a problem with our architecture. In either case I still
don't see this as a problem because the Hibernate Session remains open
throughout the entire request/response cycle, so it should be impossible
to end up with a detached object that ends up causing problems.
The only thing that happens after an XXXManager write method is called
is that we commit a transaction, but a single Session can use multiple
transactions without any problems. The Open Session in View link you
sent out even suggests this can be a good idea ...
"Can I use two transactions in one Session?
Yes, this is actually a better implementation of this pattern. One
database transaction is used to read and write data during the
processing of the request event. The second database transaction is only
used to read data, during rendering of the view. ... "
That is the exact pattern that I am implementing. Namely, the first
time something is fetched from the db the Session is opened and a
Transaction begins. *If* a write operation occurs we do it once and
commit the changes to the db, then open up a new Transaction for any
other queries that need to happen in order to render the view. At the
end of the request we close the Session and return the response.
-- Allen
