Thanks Patrick!
On 9/22/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
> I don't think so. In a per-session model you can do a
> fetch->detach->validate->merge pattern which means that your writes don't
> persist if you fail validation. With the long-session model you can't do
> that detach
more Connections than you do with a
session per thread or some other pattern.
--- Pat
-Original Message-
From: Pete [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 22, 2005 2:40 PM
To: Tapestry users
Subject: Re: Another Stupid Hibernate Question (TP4)
the third soluti
some other pattern.
--- Pat
> -Original Message-
> From: Pete [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 22, 2005 2:40 PM
> To: Tapestry users
> Subject: Re: Another Stupid Hibernate Question (TP4)
>
> the third solution sounds pretty nice...
t;[EMAIL PROTECTED]>
wrote:
Please see comments below.
-Original Message-
From: Henri Dupre [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 22, 2005 12:34 PM
To: Tapestry users
Subject: Re: Another Stupid Hibernate Question (TP4)
On 9/22/05, Patrick Casey <
Please see comments below.
> -Original Message-
> From: Henri Dupre [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 22, 2005 12:34 PM
> To: Tapestry users
> Subject: Re: Another Stupid Hibernate Question (TP4)
>
> On 9/22/05, Patrick Casey <
On 9/22/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
>
> There's a third approach you should definitely consider:
>
> Never detatch your persistent objects and use a long session. It'll
> prevent all those nasty dirty collection, uninitialized collection, and lazy
> initialization p
persistent objects it doesn't
really need.
--- Pat
> -Original Message-
> From: Peter Ertl [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 22, 2005 10:50 AM
> To: Tapestry users
> Subject: RE: Another Stupid Hibernate Question (TP4)
>
> you sound like a
incredible hard time. And I just don't want to
write SQL myself :-)
regards
Peter
> --- Ursprüngliche Nachricht ---
> Von: "Kurtis Williams" <[EMAIL PROTECTED]>
> An: "Tapestry users"
> Kopie: <[EMAIL PROTECTED]>
> Betreff: RE: Another Stup
Just for the sake of discussion, the approach I took was to use service
objects for all hibernate and business operations. I inject the service
into the page with @InjectObject("spring:myService") and then my page
code ends up being very small. Plus my services are tested separately in
their own un
hidden fields, parameters, etc. - use "View Source" to make sure there
aren't unexpected hibernate serializations into your page.)
-Original Message-
From: Cory Watson [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 17, 2005 9:20 PM
To: Tapestry users
Subject: Another St
Look at this http://www.theserverside.com/articles/article.tss?l=HivemindBuzz,
maybe helps you to better understand hivemind and also there's a good
hivemind session service (which I use :) which can be injected into
services
2005/9/18, Chris Nelson <[EMAIL PROTECTED]>:
> I use the OpenSessionInVi
I use the OpenSessionInViewFilter that comes with
Spring in Trails. It's been working fine for me in
TP4.
--Chris
--- Cory Watson <[EMAIL PROTECTED]> wrote:
> I can't find a definitive answer for how to utilize
> Hibernate
> properly in Tapestry.
>
> I used to use a 'Session In View' by way
I can't find a definitive answer for how to utilize Hibernate
properly in Tapestry.
I used to use a 'Session In View' by way of a HibernateHelper class
with that held the session in a ThreadLocal, then utilized my
Engine's cleanupAfterRequest(). This suddenly no longer works right
in TP4
13 matches
Mail list logo