We don't walk over the models because we don't have components and models.
johan
On 2/27/06,
Maurice Marrink <[EMAIL PROTECTED]> wrote:
I think he is already doing that johan, hence the question about the
re-attaching.
Although there seems to be something going wrong because all models
are detatched at the end of a request (unless you are nesting models
and you don't propagate the detach call to the nested model). on
detach the loadabledetachable model should set the hibernate object to
null and only store the class and the id so when later attach is
called it can load them from the session.
That is what you usually use however if for some strange reason you
must keep the hibernateobject in your model then you have to resort to
stuff like re-attach or merge (all in the hibernate session object )
Personaly i have some experiance with re-attching hibernate objects to
the session and it is not something you can use out of the box. For
instance re-attch throws an exception if an object with the same id is
already loaded in the session (you need to do some dirty tricks to
find out if this is the case since hibernate does not have an api for
this). Re-attach only works for the hibernateobject you re-attached,
meaning if i have an object A with a list of objects of type C and a
reference to object B, after re-attching i can only safely call A and
C. if B has any lazy list they will give me an exception because they
have not been re-attched.
Maurice
On 2/24/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
> personally i wouldn't keep hibernate objects in my models.
> 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
> > > > Wicket-user@lists.sourceforge.net
> > > <mailto:Wicket-user@lists.sourceforge.net>
> > > > <mailto: Wicket-user@lists.sourceforge.net
> > > <mailto:Wicket-user@lists.sourceforge.net>>
> > > >
> 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
> > > Wicket-user@lists.sourceforge.net
> > > <mailto: Wicket-user@lists.sourceforge.net >
> > >
> 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
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
-------------------------------------------------------
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?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
