Hi Renat,
Thanks a lot for your explain. However, my question is what' is the
elegant way to prevent
potential LazyInitializationException when Tapestry5 processing form
submitting, since action request and render request are in 2 different
threads now, thus the hibernate Sessions in 2 requests should be
different instances.
For instance:
I have a class called People:
People {
String firstname;
@lazyLoading Set addresses;
}
Page1 {
@Inject Session session;
@Persist People people;
onSubmitFromForm1 {
session.save(people);
// people.getAddresses().size();
}
}
Steps:
1. edit a people' firstname in Page1, It's possible I don't need to
show address here, so get Addresses() is NOT called,
2. I submit the form, modify firstname, save people.
3. I render people (already be detached) in page1 again WITH address
info, i.e. call getAddresses(); here LazyInitializationException
happens. because the hibernate session for step 2 has been closed. my
solutions is to call people.getAddresses().size() explicitly to force
the lazyloading set be opened in step2, but I don't think this is a
good way.
I knew merge() or refresh() both work, but where should I call them?
in beginRender()? sounds not good.
Any suggestion?
Thanks
Richard
On Nov 22, 2007 4:37 AM, Renat Zubairov <[EMAIL PROTECTED]> wrote:
> Hello Yunhua,
>
> Depends on why do you have it :) Most probably you just store the object
> you've got from Hibernate in the session and since every object associated
> with persistent context (it's actually a JPA term, but it is very well
> defined therefore we can use it for Hibernate env. also) has a reference to
> already closed session you might be having this exception.
> There are multiple consideration need to be taken into account, first is you
> might be interesting in storing object in the session and let user edit it
> over multiple pages, in this case you would better use detach/attach
> strategy (as was already mentioned in this thread), but please take care
> that you have an optimistic concurrency control in place (every object has a
> version in it and versions are checked by hibernate in case two users have
> conflicting changes). With this solution we are going to the area of
> emulating long transactions and different session management patterns for
> Hibernate (google for long-living session).
> Another use case is when it's just simpler to store object in the session
> therefore you might just considering storing primary key of the object and
> then fetch it from the Hibernate every time page is loaded, this will
> potentially require shorter transactions (entity is loaded, modified and
> saved during one request). One very elegant way to do that in T4 was
> DataSquezers, they can generally encode "any" hibernate entity to it's
> primary key automatically and then restore it during the next request (you
> can check Honeycomb for that), also as far as I remember Honeycomb also had
> a feature that in case hibernate entity is stored in session by Tapestry
> then it is also doing all kind of conversion on it also (but I'm not sure
> wherever it works, check honeycomb).
>
> Renat
>
>
>
> On 21/11/2007, Yunhua Sang <[EMAIL PROTECTED]> wrote:
> >
> > Hi Renat,
> >
> > Do you have some good ideas to prevent LazyInitializationException be
> > thrown out after form submitting? My current solution looks not smart:
> > explicitly call collection.size() in the first thread.
> >
> > Thanks
> > Yunhua
> >
> > On Nov 21, 2007 9:54 AM, Renat Zubairov <[EMAIL PROTECTED]> wrote:
> > > There is a simpler solution that works is to rollback the DB transaction
> > in
> > > case validation fails. So we are actually get a transaction from the
> > > Hibernate session and roll it back therefore no changes are efficient in
> > the
> > > session.
> > > There is not very flexible solution but works for simpler cases.
> > > There are different solution, e.g. working on detached objects or
> > clearing
> > > session.
> > >
> > > Renat
> > >
> > >
> > > On 30/10/2007, Maximilian Weißböck <[EMAIL PROTECTED]>
> > wrote:
> > > >
> > > > Oh yes, this is really a problem we actually had in a Tapestry 4
> > > > Application. We had to use (ugly) DTO Objects to avoid this problem.
> > > >
> > > > As far as I can remember, this problem is addressed in JSF with its
> > > > complex
> > > > render cycle. Values are stored in intermediate objects until
> > > > validation is completed and only then are copied to the bean data
> > object.
> > > >
> > > > Would be interesting if there could be a similar soultion for T5?
> > > >
> > > > Max
> > > >
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: lasitha [mailto:[EMAIL PROTECTED]
> > > > > Gesendet: Dienstag, 30. Oktober 2007 15:29
> > > > > An: Tapestry users
> > > > > Betreff: Re: T5: Tapestry-Hibernate, do we have to save()?
> > > > >
> > > > > On 10/30/07, Angelo Chen <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > is this really needed? I got confused, why the changes are
> > > > > saved without
> > > > > > calling _session.save()?
> > > > >
> > > > > Angelo, this is default hibernate behaviour. See:
> > > > > http://www.hibernate.org/hib_docs/v3/reference/en/html/objects
> > > > > tate.html#objectstate-modifying
> > > > >
> > > > > However, your post brings up an interesting question: will the
> > > > > object's state be persisted even after validation fails? My first
> > > > > guess is might actually be a problem.
> > > > > Consider:
> > > > > 1. Object is retrieved in onAttached() and associated with a
> > > > > new session,
> > > > > 2. Fields are updated with values from the form submission (lets
> > > > > assume they are valid),
> > > > > 3. Some cross-validation fails in onValidate() - so onSuccess() is
> > > > > never called, but...
> > > > > 4. As the thread cleans up, the HibernateSessionManager commits the
> > > > > transaction anyway and the invalid values are persisted!
> > > > >
> > > > > I'd like to test this and look around the lists a bit but am
> > throwing
> > > > > this out in case others have thoughts.
> > > > >
> > > > > Cheers, lasitha.
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > 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]
> > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Renat Zubairov
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Best regards,
> Renat Zubairov
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
