Let one of the Hibernate caches do that for you down below (closer to youre data)
instead of in the ui level/models.
On 2/23/06, Gili <[EMAIL PROTECTED]> wrote:
Ah! Thank you :)
You seemed to have missed my question regarding clustering. Do I need
to fully detach LoadableDetachableModel on resource close or is it
sufficient to reattach the Hibernate objects to a new Session on the
next request? Will the latter cause problems in clustering environments?
Thank you,
Gili
Johan Compagner wrote:
> Iresourcestream.close()
>
> On 2/23/06, *Gili* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> I meant I haved a Resource that gets its data from the
> database. So I
> wrapped my Hibernate object in a LoadableDetachableModel. Basically
> what
> I am noticing is this:
>
> 1) First request comes in
> 2) New Hibernate session is opened
> 3) Resource.getData() gets invoked
> 4) LoadableDetachableModel.attach() gets invoked and its object is
> returned. Resource uses this to generate its data.
> 5) Data is returned to client, Hibernate session is closed at the end of
> the request (by my servlet filter)
>
> 6) Second request comes in
> 7) LoadableDetachableModel thinks it is still attached
> 8) I try using the Hibernate object it returns but it is now
> disconnected from the Session so I have to explicitly reconnect it to a
> new session.
>
> Ideally I'd like to have a mechanism which lets me know when
> I should
> reconnect the Hibernate objects to the session so if
> Resource.getLength(), getData() get invoked in a single HTTP request, I
> only attach them to the session once.
>
> In my original image I was looking for a way to detach()
> LoadableDetachableModel at the end of each HTTP request, but I realize
> now this might be overkill. It is far more expensive to re-attach a
> LoadableDetachableModel than simply reattach its resulting object to the
> Hibernate session.
>
> So two questions:
>
> 1) Is there a good reason to re-attach the LoadableDetachableModel at
> the beginning of each HTTP request? Or is it enough to simply re-attach
> the Hibernate object? Will the latter break anything in a clustering
> environment?
>
> 2) Does it make sense for Wicket to provide some sort of mechanism/hook
> to let the resource know when the HTTP request begins/ends so it can
> reattach its model objects (if any exist) to the database?
>
> Thank you,
> Gili
>
> Johan Compagner wrote:
> > i guess you are now talking about a Component that is directly
> its own
> > Resource Streamer?
> > of do you have Shared Resources with a detachablemodel? That would be
> > strange because that
> > doesn't make anysense for wicket (we don't attach/detach it)
> >
> > But for a component and a model impl that has the resource this
> > shouldn't be a problem to begin with
> > Because the stream is done in one go so contenttype, data.
> > And last modified is not checked for those so only a last modifed
> > request doesn't come anyway
> > And if it did then still we need to detach it because over request
> > everything needs to be detached.
> >
> > johan
> >
> >
> >
> > On 2/23/06, *Gili* < [EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>>> wrote:
> >
> > Hi,
> >
> > Currently resources have no concept of the beginning
> or end
> > of request
> > because most resources have no need for them. Problem is, if
> you have a
> > resource that is backed up by a DetachableModel there needs
> to be a way
> > to tell the model when to attach or detach itself. Currently
> the only
> > safe (but inefficient) way to do this seems to be to attach()
> at the
> > beginning of a method call and detach() at the end of it.
> >
> > Ideally I'd like to give resources some sort of
> concept of the
> > beginning and end of a request so if Wicket knows it is about
> to query
> > the resource length, content-type and data I will only need to
> > attach/detach once across those three calls instead of three
> times. Is
> > such a thing possible or maybe you have a better idea? I can
> file a RFE
> > if needed.
> >
> > Thank you,
> > Gili
> > --
> > http://www.desktopbeautifier.com/
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking
> scripting
> > language
> > that extends applications into web and mobile media. Attend
> the live
> > webcast
> > and join the prime developer group breaking into this new coding
> > territory!
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642>
> >
> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> < http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642>>
> > _______________________________________________
> > Wicket-user mailing list
> > [email protected]
> <mailto:[email protected]>
> > <mailto: [email protected]
> <mailto:[email protected]>>
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> <https://lists.sourceforge.net/lists/listinfo/wicket-user >
> >
> >
>
> --
> http://www.desktopbeautifier.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642>
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> <mailto:[email protected] >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
