Yes, it would be most helpful if you could describe your solution using
hivetranse for the following issues:
1) session per request - my experience was that if I called one
transaction demarcated service method, and then another one, two
hibernate sessions were created, thus defeating the use of the hibernate
session as a primary cache
2) open session in view - due to the possibility of multiple
simultaneous hibernate sessions in one request, turning on hivetranse
open session in view feature leads to the problem Ted Steen reported
(org.hibernate.HibernateException: Illegal attempt to associate a
collection with two open sessions). The alternative is to manually
initialize all objects which will be displayed in the view, not that bad
but not ideal.
3) approach for committing the transaction for an updated persistent
object - once the persistent object has been updated by tapestry, what
service method is there to call for committing the update? There is
often nothing more to do than to commit the transaction, triggering
hibernate to do its magic to save the changes. Using hivetranse I had to
create an explicit update method to call session.update() on my
persistent object. It would not be necessary to reassociate the updated
persistent object with the session if there was truly a "session per
request". The objective in a form post should be, IMO, to have the
object retrieved, updated by tapestry, then committed, all within a
single transaction. The only way I could see to accomplish this with
hivetranse would be to put the transaction demarcation on a request
filter. But if the commit happens at the end of the .service() method,
it is too late to do any error handling if the commit fails.
In short, what I want is a single hibernate session per request, a way
to commit the transaction after all updates have been made to persistent
objects but while I still have a chance to handle any exceptions, and
the ability to keep that session open during the rendering of the view.
I very much wanted to use hivetranse but couldn't figure out an approach
that was compatible with my understanding of a correct use of hibernate.
A documented solution would be most helpful. Thanks!
-- Mark R
Nick Faiz wrote:
Hi James,
Yes, I'm aware that there are different approaches too. It seems to me
that this same topic has been bandied back and forth across the list
several times in the last month or so.
Most of you can probably stop reading now, being used to this answer and
question routine yourselves.
Our approach is very simplistic - we just follow the docs at the
HiveUtils site. We create several hivemind components, session,
sessionfactory, & transaction interceptor. Anything that requires the
session is made a Hivemind component and injected with it, while having
its methods intercepted by the TransactionInterceptor.
Perhaps we should create a wiki page, somewhere, which can describe, in
simple terms, techniques used for session per request/conversation
configurations? This should be a solved problem, given the amount of
time people have put into it discussing it.
Cheers,
Nick
James Carman wrote:
There's nothing wrong with it at all. It's just a different approach. I
had to write much less code to achieve the same result. And, I'm
reusing a
proven technology (the Spring classes) which people are familiar with
already.
-----Original Message-----
From: Nick Faiz [mailto:[EMAIL PROTECTED] Sent: Sunday, April 23,
2006 9:21 PM
To: Tapestry users
Subject: Re: I have a dream...
I still don't see what's wrong with HiveUtils - it just works for me.
I spent around 30 minutes configuring it 6 weeks ago and they've been
no problems.
Nick
Andreas Bulling wrote:
Spring may provide all of the things on my list of wishes already...
I don't know as I only tried to use it for several days and changed
to Hivemind as it's the tool Tapestry is build upon/uses and I don't
need most of Spring's stuff (at least not at the moment).
That's why I wrote that I dream of having something similar
for _Hivemind_: Because Tapestry is based on Hivemind and I don't want
to be forced to use Spring if I don't need all the other stuff.
To come back to my original statement:
Perhaps we could adapt the code from Spring which handles
sessions/transactions/persistent objects and include it into
Hivemind? I don't know the internals of Hivetranse - perhaps
this is already a project which takes this way?
Perhaps if we can agree on HiveTranse as a possible basis for
further development (actually I have to say that I have _nearly_
no problems concerning sessions/transactions using HiveTranse)
There was another thread on this list some days ago - what should
be changed/included into HiveTranse, the OpenSessionInView pattern
for example, a data squeezer, what else?
But by all means I didn't want to start another Hivemind vs. Spring
flamewar
so please keep calm ;)
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
