Re: [Wicket-user] How to detect page switch

[Pierre-Yves Saumont]

Yes, that's what I am doing. I will then store the objects in the 
session and later add support for storing them in a temp table if needded.

In case the objects are to be saved in the database, what would be the 
best approach? I the same table as the actual object (needs one more 
field to indicate if it is an original clone or an actual object)? Or in 
a separate table (needs to double the number of tables)?

Pierre-Yves

Igor Vaynberg a écrit :
> if you keep a clone of the object before the change in your session 
> (which sounds like you do) then there wont be any issues. you have all 3 
> states needed to merge correctly.
> 
> -Igor
> 
> 
> On 9/13/06, *Pierre-Yves Saumont* <[EMAIL PROTECTED]  PROTECTED]>> 
> wrote:
> 
> I eventually implemented something very close to what you describe.
> Basically it is a sort of optimistic locking with field merging so that
> update fails only for those fields that are found different at update
> time than at read time. In such case, fields that can be updated are
> and
> those that can't are left unchanged. The form is redisplayed so the user
> can see the two versions. If he saves a second time, all fields are
> updated.
> 
> However, to achieve this, I need to implement pessimistic locking for a
> short time, between the time the form is redisplayed and the time the
> user saves again or cancel. (Pessimistic locking is also implemented
> between a delete request and its confirmation or cancellation.)
> 
> The problem is that the user can make a third choice and go to have a
> coffe break. So, the lock that the user (in fact the session) has
> acquire will expire after some configurable time. It works by writing
> the session id, the lock time and the maximum delay into the database.
> That way, if another user comes, he can see if there is a lock and if
> this lock is active, and act accordingly. This is supposed to solve the
> problem of the user not releasing a lock.
> 
> There is still a problem: in the optimistic/merge scenario, I must have
> a copy of the field values at read time to compare with the modified
> fields and the actual fields. For this, I keep a reference to the
> hibernate object. The modified fields are in a value object.
> 
> Not holding a reference to the original object would not be relevant if
> I would still hold a reference to the value object. It makes little
> sense to throw one away and keep the other. But there is no hibernate
> related problem, since the object is never used to persist or merge the
> data.
> 
> Now, it could be possible to keep only the ids of the objects. For
> this,
> I would have to store the two objects in the database. But I do not
> think this would be rewarding. I would need to create special tables for
> this, write the two objects, read them, and eventually delete them. I
> prefer to have small objects (in case of big entities, just break them
> in smaller parts) and store them for the duration of the pseudo
> transaction. At worst, they will be thrown away when the session expires
> and the locks in the database will have themsevles expired much longer
> before.
> 
> The real question is "which potential problem is hidden in this scenario
> and will suddenly jump out when the app will be in production ? :-("
> 
> Pierre-Yves
> 
> Johan Compagner a écrit :
>  > you really shouldn't lock objects over request..
>  > Because you don't controll anything. He can close the browser or
> go away
>  > In a swing app where you have a connection to you can at least do
>  > something about it
>  > (and show that to the user that he looses it and take it again on a
>  > focus of a field)
>  >
>  > But long transactions or locks over request is in my eyes bad
> praktisch
>  > that shouldn't be done in a webapp.
>  >
>  > Maybe with full use of ajax you can get to the behaviour a bit that a
>  > fat client would have..
>  >
>  > But i prefer other way. Just let it change it and if it did
> change (does
>  > that really happen a lot? i can't believe that)
>  > then report that first back to the user that a save couldn't happen
>  > because another person did change it already
>  > and do show those changes (try to merge it)
>  >
>  > johan
>  >
>  >
>  > On 9/12/06, *Pierre-Yves Saumont* <[EMAIL PROTECTED]
>   PROTECTED]>>>
>  > wrote:
>  >
>  > Hi,
>  >
>  > Is there a Wicket (ie really smart) way to detext when the
> user switch
>  > to another page?
>  >
>  > The use case is to release locks that a user might have put
> on database
>  > records with pessimistic locking when the user switch to
>

Re: [Wicket-user] How to detect page switch

[Pierre-Yves Saumont]

Thanks Martijn, Your implementation is inspiring. I will rewrite mine 
following your example. Merging adds some problems in itself, and some 
more if you want to be smart to the user when some field conflict. There 
even is a problem when no fields conflict because the resulting record 
might not be what the user expected when saving. So it is probably 
necessary to return the actual and modified values in any case if 
versions differ. (ie even if there was no field confict.)

Pierre-Yves

Martijn Dashorst a écrit :
> Just a general comment on this thread, I have added a VersionedForm to
> our application which will discover a stale object based on the
> version number in the object (using javax.persistence @Version
> annotation). I have described this component here:
> 
> http://jroller.com/page/dashorst?entry=wicket_goodie_hibernate_versioned_form 
> 
> 
> (BTW Frank: woogle didn't find this article!)
> 
> If a concurrent update has been detected, the form will repopulate
> with the values from the database. The user should then re enter the
> values (as the previous values were based on old information, the new
> data can invalidate his data!).
> 
> It doesn't do locking across requests, and has served our purpose. It
> may provide you with an alternative.
> 
> Martijn
> 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Martijn Dashorst]

I used the google, but knew what to look for (as I wrote it). But even I don't know everything I put on that blog by memory.I'd have to digg into roller's code to see how to publish the full list under an url. But no time for that unfortunately.
MartijnOn 9/14/06, Frank Bille <[EMAIL PROTECTED]> wrote:
On 9/14/06, Martijn Dashorst <[EMAIL PROTECTED]
> wrote:
http://jroller.com/page/dashorst?entry=wicket_goodie_hibernate_versioned_form
(BTW Frank: woogle didn't find this article!)
Hmm, I'm not sure how to fetch that with woogle. How would a normal user find the article? I can't find any "archive", "back" or "search" on your weblog. Then it's pretty hard to find it.
Frank

-Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
-- Download Wicket 1.2.2 now! New Ajax components: Tree, TreeTable and ModalWindow-- http://wicketframework.org
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Frank Bille]

On 9/14/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
http://jroller.com/page/dashorst?entry=wicket_goodie_hibernate_versioned_form(BTW Frank: woogle didn't find this article!)
Hmm, I'm not sure how to fetch that with woogle. How would a normal user find the article? I can't find any "archive", "back" or "search" on your weblog. Then it's pretty hard to find it.
Frank
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Igor Vaynberg]

if you keep a clone of the object before the change in your session (which sounds like you do) then there wont be any issues. you have all 3 states needed to merge correctly.-Igor
On 9/13/06, Pierre-Yves Saumont <[EMAIL PROTECTED]> wrote:
I eventually implemented something very close to what you describe.Basically it is a sort of optimistic locking with field merging so thatupdate fails only for those fields that are found different at updatetime than at read time. In such case, fields that can be updated are and
those that can't are left unchanged. The form is redisplayed so the usercan see the two versions. If he saves a second time, all fields are updated.However, to achieve this, I need to implement pessimistic locking for a
short time, between the time the form is redisplayed and the time theuser saves again or cancel. (Pessimistic locking is also implementedbetween a delete request and its confirmation or cancellation.)The problem is that the user can make a third choice and go to have a
coffe break. So, the lock that the user (in fact the session) hasacquire will expire after some configurable time. It works by writingthe session id, the lock time and the maximum delay into the database.That way, if another user comes, he can see if there is a lock and if
this lock is active, and act accordingly. This is supposed to solve theproblem of the user not releasing a lock.There is still a problem: in the optimistic/merge scenario, I must havea copy of the field values at read time to compare with the modified
fields and the actual fields. For this, I keep a reference to thehibernate object. The modified fields are in a value object.Not holding a reference to the original object would not be relevant ifI would still hold a reference to the value object. It makes little
sense to throw one away and keep the other. But there is no hibernaterelated problem, since the object is never used to persist or merge thedata.Now, it could be possible to keep only the ids of the objects. For this,
I would have to store the two objects in the database. But I do notthink this would be rewarding. I would need to create special tables forthis, write the two objects, read them, and eventually delete them. I
prefer to have small objects (in case of big entities, just break themin smaller parts) and store them for the duration of the pseudotransaction. At worst, they will be thrown away when the session expiresand the locks in the database will have themsevles expired much longer
before.The real question is "which potential problem is hidden in this scenarioand will suddenly jump out when the app will be in production ? :-("Pierre-YvesJohan Compagner a écrit :
> you really shouldn't lock objects over request..> Because you don't controll anything. He can close the browser or go away> In a swing app where you have a connection to you can at least do> something about it
> (and show that to the user that he looses it and take it again on a> focus of a field)>> But long transactions or locks over request is in my eyes bad praktisch> that shouldn't be done in a webapp.
>> Maybe with full use of ajax you can get to the behaviour a bit that a> fat client would have..>> But i prefer other way. Just let it change it and if it did change (does> that really happen a lot? i can't believe that)
> then report that first back to the user that a save couldn't happen> because another person did change it already> and do show those changes (try to merge it)>> johan>>
> On 9/12/06, *Pierre-Yves Saumont* <[EMAIL PROTECTED] [EMAIL PROTECTED]>>> wrote:>> Hi,>> Is there a Wicket (ie really smart) way to detext when the user switch
> to another page?>> The use case is to release locks that a user might have put on database> records with pessimistic locking when the user switch to another page.>> Pierre-Yves
>>> ->> Using Tomcat but need to do more? Need to support web services,> security?> Get stuff done quickly with pre-integrated technology to make your
> job easier> Download IBM WebSphere Application Server v.1.0.1 based on Apache> Geronimo> 
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642> > ___> Wicket-user mailing list> Wicket-user@lists.sourceforge.net> Wicket-user@lists.sourceforge.net>> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>-
Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bi

Re: [Wicket-user] How to detect page switch

[Martijn Dashorst]

Just a general comment on this thread, I have added a VersionedForm to
our application which will discover a stale object based on the
version number in the object (using javax.persistence @Version
annotation). I have described this component here:

http://jroller.com/page/dashorst?entry=wicket_goodie_hibernate_versioned_form

(BTW Frank: woogle didn't find this article!)

If a concurrent update has been detected, the form will repopulate
with the values from the database. The user should then re enter the
values (as the previous values were based on old information, the new
data can invalidate his data!).

It doesn't do locking across requests, and has served our purpose. It
may provide you with an alternative.

Martijn

-- 
Download Wicket 1.2.2 now! New Ajax components: Tree, TreeTable and ModalWindow
-- http://wicketframework.org

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Pierre-Yves Saumont]

I eventually implemented something very close to what you describe. 
Basically it is a sort of optimistic locking with field merging so that 
update fails only for those fields that are found different at update 
time than at read time. In such case, fields that can be updated are and 
those that can't are left unchanged. The form is redisplayed so the user 
can see the two versions. If he saves a second time, all fields are updated.

However, to achieve this, I need to implement pessimistic locking for a 
short time, between the time the form is redisplayed and the time the 
user saves again or cancel. (Pessimistic locking is also implemented 
between a delete request and its confirmation or cancellation.)

The problem is that the user can make a third choice and go to have a 
coffe break. So, the lock that the user (in fact the session) has 
acquire will expire after some configurable time. It works by writing 
the session id, the lock time and the maximum delay into the database. 
That way, if another user comes, he can see if there is a lock and if 
this lock is active, and act accordingly. This is supposed to solve the 
problem of the user not releasing a lock.

There is still a problem: in the optimistic/merge scenario, I must have 
a copy of the field values at read time to compare with the modified 
fields and the actual fields. For this, I keep a reference to the 
hibernate object. The modified fields are in a value object.

Not holding a reference to the original object would not be relevant if 
I would still hold a reference to the value object. It makes little 
sense to throw one away and keep the other. But there is no hibernate 
related problem, since the object is never used to persist or merge the 
data.

Now, it could be possible to keep only the ids of the objects. For this, 
I would have to store the two objects in the database. But I do not 
think this would be rewarding. I would need to create special tables for 
this, write the two objects, read them, and eventually delete them. I 
prefer to have small objects (in case of big entities, just break them 
in smaller parts) and store them for the duration of the pseudo 
transaction. At worst, they will be thrown away when the session expires 
and the locks in the database will have themsevles expired much longer 
before.

The real question is "which potential problem is hidden in this scenario 
and will suddenly jump out when the app will be in production ? :-("

Pierre-Yves

Johan Compagner a écrit :
> you really shouldn't lock objects over request..
> Because you don't controll anything. He can close the browser or go away
> In a swing app where you have a connection to you can at least do 
> something about it
> (and show that to the user that he looses it and take it again on a 
> focus of a field)
> 
> But long transactions or locks over request is in my eyes bad praktisch 
> that shouldn't be done in a webapp.
> 
> Maybe with full use of ajax you can get to the behaviour a bit that a 
> fat client would have..
> 
> But i prefer other way. Just let it change it and if it did change (does 
> that really happen a lot? i can't believe that)
> then report that first back to the user that a save couldn't happen 
> because another person did change it already
> and do show those changes (try to merge it)
> 
> johan
> 
> 
> On 9/12/06, *Pierre-Yves Saumont* <[EMAIL PROTECTED]  PROTECTED]>> 
> wrote:
> 
> Hi,
> 
> Is there a Wicket (ie really smart) way to detext when the user switch
> to another page?
> 
> The use case is to release locks that a user might have put on database
> records with pessimistic locking when the user switch to another page.
> 
> Pierre-Yves
> 
> 
> -
> 
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> 
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> 
> 
> 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mai

Re: [Wicket-user] How to detect page switch

[Johan Compagner]

you really shouldn't lock objects over request.. Because you don't controll anything. He can close the browser or go awayIn a swing app where you have a connection to you can at least do something about it(and show that to the user that he looses it and take it again on a focus of a field)
But long transactions or locks over request is in my eyes bad praktisch that shouldn't be done in a webapp.Maybe with full use of ajax you can get to the behaviour a bit that a fat client would have..
But i prefer other way. Just let it change it and if it did change (does that really happen a lot? i can't believe that)then report that first back to the user that a save couldn't happen because another person did change it already
and do show those changes (try to merge it)johanOn 9/12/06, Pierre-Yves Saumont <[EMAIL PROTECTED]> wrote:
Hi,Is there a Wicket (ie really smart) way to detext when the user switch
to another page?The use case is to release locks that a user might have put on databaserecords with pessimistic locking when the user switch to another page.Pierre-Yves-
Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Eelco Hillenius]

On 9/12/06, Pierre-Yves Saumont <[EMAIL PROTECTED]> wrote:
> Thank you for this clarification. So it appears that, in an unclusterd
> context, the problem is not with storing references *in sessions*, but
> simply with storing references. I am using hibernate objects and I need
> to keep to copies of the data, so I am creating a value object plus I
> keep the original hibernate object. Perhaps I would better create 2
> value objects and throw away the hibernate object (in case this object
> is much bigger than a simple value object??). I must check for this.
> (But this is not Wicket related ;-).

A common problem with things like Hibernate objects is that they might
get stale (disconnected from the session they were retrieved in),
which results in problems with things like lazy collections. Also, if
you use a transaction per request (e.g. using servlet filters or a
custom request cycle) like some people have reported doing, you have
to be very careful you're not updating objects you didn't want
updated. The latter is an argument for using value objects (which I
don't like tbh... too much code duplication) and the first is an
argument for using detachable models and thus storing only the minimal
info (if any) for retrieving the proper objects.

Eelco

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Pierre-Yves Saumont]

Thank you for this clarification. So it appears that, in an unclusterd 
context, the problem is not with storing references *in sessions*, but 
simply with storing references. I am using hibernate objects and I need 
to keep to copies of the data, so I am creating a value object plus I 
keep the original hibernate object. Perhaps I would better create 2 
value objects and throw away the hibernate object (in case this object 
is much bigger than a simple value object??). I must check for this. 
(But this is not Wicket related ;-).

Thanks again

Pierre-Yves

Eelco Hillenius a écrit :
> On 9/12/06, Pierre-Yves Saumont <[EMAIL PROTECTED]> wrote:
>> Matej, I do not understand your point :-( The object does not get
>> replicated when a reference to it is stored in the session. So I
>> understand point b, but in case no clustering is used, why would there
>> be a memory problem? Putting a reference in the session is just a way to
>> keep a handle on the  object. Having the reference the session is not
>> different from having it anywhere else, as far as memory is concerned.
>> Or is it?
> 
> That,, of course, depends on where that object comes from and how long
> lived it would be if it were not put in the session. For instance, if
> you have some objects you get from an ORM (like Hibernate), they
> typically only have to exist for a short time, e.g. during a
> transaction, interpreting the results of a query, etc. Usually, this
> means that such objects live for one request. However, if you
> references to such objects in your components or models, they'll live
> as long as those components/ models live, which might be for the
> duration of the session. But if you would store e.g. only the ids of
> those objects, or the query to get them or just a reference to a
> service that knows how to get them, you'll use less memory. This is
> the main reason we have detachable models.
> 
> Replication, like you said, only happens when you run in a cluster
> *and* you use http session replication *and* you use http session as
> session store (HttpSessionStore) *or* when a server tries to persist
> sessions e.g. on shutdown so that on startup it can pick up it's
> sessions again.
> 
> Eelco
> 
> 
> 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Eelco Hillenius]

On 9/12/06, Pierre-Yves Saumont <[EMAIL PROTECTED]> wrote:
> Matej, I do not understand your point :-( The object does not get
> replicated when a reference to it is stored in the session. So I
> understand point b, but in case no clustering is used, why would there
> be a memory problem? Putting a reference in the session is just a way to
> keep a handle on the  object. Having the reference the session is not
> different from having it anywhere else, as far as memory is concerned.
> Or is it?

That,, of course, depends on where that object comes from and how long
lived it would be if it were not put in the session. For instance, if
you have some objects you get from an ORM (like Hibernate), they
typically only have to exist for a short time, e.g. during a
transaction, interpreting the results of a query, etc. Usually, this
means that such objects live for one request. However, if you
references to such objects in your components or models, they'll live
as long as those components/ models live, which might be for the
duration of the session. But if you would store e.g. only the ids of
those objects, or the query to get them or just a reference to a
service that knows how to get them, you'll use less memory. This is
the main reason we have detachable models.

Replication, like you said, only happens when you run in a cluster
*and* you use http session replication *and* you use http session as
session store (HttpSessionStore) *or* when a server tries to persist
sessions e.g. on shutdown so that on startup it can pick up it's
sessions again.

Eelco

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Pierre-Yves Saumont]

Matej, I do not understand your point :-( The object does not get 
replicated when a reference to it is stored in the session. So I 
understand point b, but in case no clustering is used, why would there 
be a memory problem? Putting a reference in the session is just a way to 
keep a handle on the  object. Having the reference the session is not 
different from having it anywhere else, as far as memory is concerned. 
Or is it?

Pierre-Yves

Matej Knopp a écrit :
> Putting large objects into session is ok, as long as you
> 
> a) have enough memory and can afford it
> b) don't replicate the session (clustering).
> 
> -Matej
> 
> Pierre-Yves Saumont wrote:
>> I already tried this method, but it is called just before the user can 
>> see the page. What I need is to do something when he leaves the page.
>>
>> However, I think I have found an acceptable solution. I would make all 
>> my data objects implements an interface (let's say Lockable) and 
>> retain the last locked object in the session. That way, I can release 
>> the last locked object on each new request (if needed). The risk is to 
>> have the last object locked until the session expires, but that's 
>> acceptable in my use case.
>>
>> However, I red many times that big objects should not be put in the 
>> session. Putting an object in the session is just a matter of 
>> retaining a reference to it. So it should not cost much. Or do I miss 
>> something?
>>
>> Pierre-Yves
>>
>> Eelco Hillenius a écrit :
 Is there a Wicket (ie really smart) way to detext when the user switch
 to another page?

 The use case is to release locks that a user might have put on database
 records with pessimistic locking when the user switch to another page.
>>> For every request target that was set during a request (like for
>>> everytime you called setResponsePage), onDetach will be called at the
>>> end of the request handling. This is the place where you should clean
>>> up resources for normal requests.
>>>
>>> Eelco
>>>
>>> - 
>>>
>>> Using Tomcat but need to do more? Need to support web services, 
>>> security?
>>> Get stuff done quickly with pre-integrated technology to make your 
>>> job easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
>>> Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> ___
>>> Wicket-user mailing list
>>> Wicket-user@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wicket-user
>>>
>>>
>>>
>>
>>
>> -
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job 
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> ___
>> Wicket-user mailing list
>> Wicket-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wicket-user
>>
> 
> 
> 
> 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Matej Knopp]

Putting large objects into session is ok, as long as you

a) have enough memory and can afford it
b) don't replicate the session (clustering).

-Matej

Pierre-Yves Saumont wrote:
> I already tried this method, but it is called just before the user can 
> see the page. What I need is to do something when he leaves the page.
> 
> However, I think I have found an acceptable solution. I would make all 
> my data objects implements an interface (let's say Lockable) and retain 
> the last locked object in the session. That way, I can release the last 
> locked object on each new request (if needed). The risk is to have the 
> last object locked until the session expires, but that's acceptable in 
> my use case.
> 
> However, I red many times that big objects should not be put in the 
> session. Putting an object in the session is just a matter of retaining 
> a reference to it. So it should not cost much. Or do I miss something?
> 
> Pierre-Yves
> 
> Eelco Hillenius a écrit :
>>> Is there a Wicket (ie really smart) way to detext when the user switch
>>> to another page?
>>>
>>> The use case is to release locks that a user might have put on database
>>> records with pessimistic locking when the user switch to another page.
>> For every request target that was set during a request (like for
>> everytime you called setResponsePage), onDetach will be called at the
>> end of the request handling. This is the place where you should clean
>> up resources for normal requests.
>>
>> Eelco
>>
>> -
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> ___
>> Wicket-user mailing list
>> Wicket-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wicket-user
>>
>>
>>
> 
> 
> -
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Pierre-Yves Saumont]

I already tried this method, but it is called just before the user can 
see the page. What I need is to do something when he leaves the page.

However, I think I have found an acceptable solution. I would make all 
my data objects implements an interface (let's say Lockable) and retain 
the last locked object in the session. That way, I can release the last 
locked object on each new request (if needed). The risk is to have the 
last object locked until the session expires, but that's acceptable in 
my use case.

However, I red many times that big objects should not be put in the 
session. Putting an object in the session is just a matter of retaining 
a reference to it. So it should not cost much. Or do I miss something?

Pierre-Yves

Eelco Hillenius a écrit :
>> Is there a Wicket (ie really smart) way to detext when the user switch
>> to another page?
>>
>> The use case is to release locks that a user might have put on database
>> records with pessimistic locking when the user switch to another page.
> 
> For every request target that was set during a request (like for
> everytime you called setResponsePage), onDetach will be called at the
> end of the request handling. This is the place where you should clean
> up resources for normal requests.
> 
> Eelco
> 
> -
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> 
> 
> 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to detect page switch

[Eelco Hillenius]

> Is there a Wicket (ie really smart) way to detext when the user switch
> to another page?
>
> The use case is to release locks that a user might have put on database
> records with pessimistic locking when the user switch to another page.

For every request target that was set during a request (like for
everytime you called setResponsePage), onDetach will be called at the
end of the request handling. This is the place where you should clean
up resources for normal requests.

Eelco

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user