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
