Sorry again for the not 100% Tapestry related question, but I got such helpful
responses from my last question, and it's clear that there are a lot of people 
on
this list that have already solved these issues that I'm running into (and I'm
getting jack from the Hibernate forums ;) )...

I've implemented the "open session in view" pattern in my Tapestry application 
in
the fairly conventional way. I inject a threaded Session via Hivemind using a
service factory, and the service factory activates a transaction and creates a
ThreadCleanupListener to commit() the transaction and close the session when the
thread is done processing the user's request.  So far so good.

What I'm not sure how to do is handle situations where I may need to inform the 
user
that their transaction failed.  For example, let's say I have a typical CRUD
application to create new users for my system, and I want to be able to 
correctly
handle the scenario where an administrator attempts to create a new user with a 
name
that is already in use (a primary or unique key violation). I can't simply let 
the
ThreadCleanupListener handle the commit() in this case; if I do this, and an
exception is thrown, it is too late to inform the user since the request has 
already
been rendered.

The "Open Session in View" page on the Hibernate web site [1] states that a good
approach is to use two transactions in one Session.  If I took this approach, I
would attempt to commit the transaction in my listener method, and catch the
exception thrown from the database, and convert this into a validation error 
which
states that the username is already taken.

The problem with this is that the Hibernate documentation is quite clear that 
if any
exception occurs, the transaction should be rolled back, and the Session should 
be
closed and discarded.  Rolling back is not a problem, but if I close and 
discard the
Session, I'm no longer using "open session in view".  I'll have to go to the 
trouble
to initialize any lazy collections or proxies that the view might need before I
attempt the commit, otherwise I'll get a LazyInitializationException.

But I've read one of the Spring guys saying [2] that it's ok to begin a new
transaction on the same Session that has been rolled back, if you're only using 
it
to initialize lazy collections.  This would be nice if it were actually true; it
would simplify things for me quite a bit.  But I hestitate to rely on that, 
since
the Hibernate documentation says otherwise.

Can someone with a bit more experience with give me some advice on how to 
approach
this?  Thanks in advance...

[1] http://www.hibernate.org/43.html
[2] http://forum.springframework.org/showpost.php?p=29579&postcount=6


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to