Re: [Wicket-user] Detachable resources

[Gili]

I simply do:

theme = themeDAO.getById(theme.getId());

	where theme is my Hibernate object. So I never run into "object with 
same id is already loaded" problem you described. You gave me a good 
idea though with regard to only storing the object ID. The thing is I 
have one detachable model dependent on the value of another detachable 
model, so the ugly thing I was doing was getting the value of one from 
within the other (which would attach() it if necessary) then use that 
result to derive the value of the second. In retrospect, I don't really 
need to do this all the time. I can just do it once in the 
LoadableDetachableModel constructor, store the ID, and then only use the 
final ID I derived in the load() method. I guess I didn't think to do 
this because I am creating an anonymous subclass of 
LoadableDetachableModel and there is no way to subclass the constructor. 
I think I'll have to generate a non-anonymous subclass to make this work.


Thanks,
Gili

Maurice Marrink 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]
> 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 

Re: [Wicket-user] Detachable resources

[Johan Compagner]

His model is not detached because a Resource request is not a normal page request.We don't walk over the models because we don't have components and models.johanOn 2/27/06, 
Maurice Marrink <[EMAIL PROTECTED]> wrote:
I think he is already doing that johan, hence the question about there-attaching.Although there seems to be something going wrong because all modelsare detatched at the end of a request (unless you are nesting models
and you don't propagate the detach call to the nested model). ondetach the loadabledetachable model should set the hibernate object tonull and only store the class and the id so when later attach iscalled it can load them from the session.
That is what you usually use however if for some strange reason youmust keep the hibernateobject in your model then you have to resort tostuff like re-attach or merge (all in the hibernate session object )
Personaly i have some experiance with re-attching hibernate objects tothe session and it is not something you can use out of the box. Forinstance re-attch throws an exception if an object with the same id isalready 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 forthis). 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 andC. if B has any lazy list they will give me an exception because theyhave not been re-attched.MauriceOn 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]> > > [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, da

Re: [Wicket-user] Detachable resources

[Maurice Marrink]

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]
> > > > 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 com

Re: [Wicket-user] Detachable resources

[Johan Compagner]

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 needto fully detach LoadableDetachableModel on resource close or is itsufficient to reattach the Hibernate objects to a new Session on the
next request? Will the latter cause problems in clustering environments?Thank you,GiliJohan Compagner wrote:> Iresourcestream.close()>> On 2/23/06, *Gili* <
[EMAIL PROTECTED]> [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]> [EMAIL PROTECTED]>>  > [EMAIL PROTECTED]> 
[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 

Re: [Wicket-user] Detachable resources

[Gili]

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] 
> 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]

 > >> 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


 >

Re: [Wicket-user] Detachable resources

[Johan Compagner]

Iresourcestream.close()
On 2/23/06, Gili <[EMAIL PROTECTED]> wrote:
   I meant I haved a Resource that gets its data from the database. So Iwrapped my Hibernate object in a LoadableDetachableModel. Basically what
I am noticing is this:1) First request comes in2) New Hibernate session is opened3) Resource.getData() gets invoked4) LoadableDetachableModel.attach() gets invoked and its object isreturned. Resource uses this to generate its data.
5) Data is returned to client, Hibernate session is closed at the end ofthe request (by my servlet filter)6) Second request comes in7) LoadableDetachableModel thinks it is still attached8) I try using the Hibernate object it returns but it is now
disconnected from the Session so I have to explicitly reconnect it to anew session.   Ideally I'd like to have a mechanism which lets me know when I shouldreconnect the Hibernate objects to the session so if
Resource.getLength(), getData() get invoked in a single HTTP request, Ionly 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 aLoadableDetachableModel than simply reattach its resulting object to theHibernate 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-attachthe Hibernate object? Will the latter break anything in a clusteringenvironment?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 canreattach its model objects (if any exist) to the database?Thank you,GiliJohan 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]> [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> > ___> Wicket-user mailing list> Wicket-user@lists.sourceforge.net> 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 webcastand 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.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Detachable resources

[Gili]

	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] 
> 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

___
Wicket-user mailing list
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

Re: [Wicket-user] Detachable resources

[Johan Compagner]

 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]> wrote:
Hi,   Currently resources have no concept of the beginning or end of requestbecause 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 wayto tell the model when to attach or detach itself. Currently the onlysafe (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 thebeginning and end of a request so if Wicket knows it is about to querythe resource length, content-type and data I will only need to
attach/detach once across those three calls instead of three times. Issuch a thing possible or maybe you have a better idea? I can file a RFEif needed.Thank you,Gili--
http://www.desktopbeautifier.com/---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat 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 listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] Detachable resources

[Gili]

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
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user