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
