You might also consider emplying some kind of concurrency control for
long-living objects, i.e. automatic versionning and attach/detach
strategies.
Renat
On 20/02/2008, Davor Hrg <[EMAIL PROTECTED]> wrote:
>
> the reason you should be most concerned is that
> in one request session#1 loads the ob
the reason you should be most concerned is that
in one request session#1 loads the object
in other request session#2 loads objects
if you use relations from second request LazyLoadExceptions will happen
if you try to force old object from #1 to session#2 you can fix problems
but this is not recomen
This is a great list to have around - perhaps we can add reasons for
each of the steps. Davor I've heard what you're saying before, but I
forget the reason behind it (I assume LazyLoadException has something to
do with it). Is it for keeping http session free of large objects?
Preventing LazyLo
also,
don't persist hibernate entities, persist keys only
On Feb 20, 2008 3:01 AM, Angelo Chen <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> What is the proper way of using hibernate in T5? is following list correct?
>
> 1. Don't commit, let Tapestry-Hibernate take care of that.
> 2. Commit only if yo
Hi,
What is the proper way of using hibernate in T5? is following list correct?
1. Don't commit, let Tapestry-Hibernate take care of that.
2. Commit only if you are going to start a thread with Session as well.
3. Use session.save for the new objects, after that, any updates to the
object does
