Re: [Wicket-user] Authorization-question
Ok, so the session is not 100% safe for attaching detaching hibernate
stuff. If there is a better place to store something like a user
object i would love to here about it.
Maurice
On 7/31/06, Johan Compagner [EMAIL PROTECTED] wrote:
yes but with igors example it is possible
that the session is used over multiply request we do have a lock
But that lock doesn't lock globally over everything.
So it is possible that it gets detached from under your nose. But that is
not a problem
But it is also possible that you get a user loaded by another thread ==
hibernate session.
Session.detach() is not called in a sync block...
johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
Glad to see it was just a misunderstanding. I was afraid you guys were
gonna tell me the world isn't flat ;)
Maurice
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i wasnt suggesting setting the user on request cycle, i was suggesting
keeping the id in session and letting requestcycle hold the cache for the
request.
i didnt realize websession has attach/detach, so this can be made simpler
MySession extends WebSession {
private long userid;
private transient User user;
setUser(User u) {
userid=u.getid();
user=u;
}
getUser() {
if (user==null) {
user=loaduserbyid(userid);
}
return user;
}
detach() {
user=null;
}
-Igor
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
store is detached. second request comes in and it is dealing with
stale
data
unless you reload the user object.
correct that is why you should use an imodel or come up with your own
attach detach strategy
also storing imodel in session wont work because session doesnt have
an
imodel slot so who is going to be responsible for detaching that model
at
the end of request?
session has an onattach and ondetach method you can use.
Also the way i understand how the whole requestcycle stuff happens
(and i know you guys know way more about that then me) is that a new
requestcycleobject is created on every request by a factory so how is
the current user supposed to get set on the requestcycle?
Don't get me wrong i am not criticizing you guys, i am just curious as
to how the internals of wicket operate.
Maurice
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
but we are talking about caching here. if you store the instance of
the
user
you loaded in session that is fine for the request that loaded it. but
what
happens after that request ends? the session is closed, the instance
you
store is detached. second request comes in and it is dealing with
stale
data
unless you reload the user object.
also storing imodel in session wont work because session doesnt have
an
imodel slot so who is going to be responsible for detaching that model
at
the end of request?
-Igor
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
true, but shouldn't the lock on the session prevent that in like 95%
of all the cases?
Maurice
On 7/31/06, Johan Compagner [EMAIL PROTECTED] wrote:
A session can be used by multiply threads/request
So it will be detached by those when they are finished.
So another request can be busy with it while another calls detach on
it.
johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
i wouldn't recommend doing this in session because user entity
will
become detached, i would instead do it in the requestcycle so
the
user is loaded once per request
Yeah are you sure about this Igor? because we are also attaching
our
user object (hibernate object) to our session, lazy loading it
whenever needed. And we have not noticed it getting detached
before
the end of the request. Mats i guess this also answers your
question
about if it is possible to put an imodel in the session. however
if
you are really concerned about the db access every time you could
always store the team id in the session.
Maurice
On 7/31/06, Mats Norén [EMAIL PROTECTED] wrote:
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i wouldnt recommend doint this in session because user entity
will
become
detached, i would instead do it in the requestcycle so the
user
is
loaded
once per request
It is? I've used a User-object in session and I haven't noticed
that
it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses
the
code below?
I think I saw an example (could have been in databinder) where a
IModel was stored in session. Is that an alternative?
Re: [Wicket-user] Authorization-question
you dont store the object. store the id and load it on demand caching it for the duration of the request.-IgorOn 8/1/06, Maurice Marrink
[EMAIL PROTECTED] wrote:Ok, so the session is not 100% safe for attaching detaching hibernate
stuff. If there is a better place to store something like a userobject i would love to here about it.MauriceOn 7/31/06, Johan Compagner [EMAIL PROTECTED]
wrote: yes but with igors example it is possible that the session is used over multiply request we do have a lock But that lock doesn't lock globally over everything. So it is possible that it gets detached from under your nose. But that is
not a problem But it is also possible that you get a user loaded by another thread == hibernate session. Session.detach() is not called in a sync block... johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote: Glad to see it was just a misunderstanding. I was afraid you guys were gonna tell me the world isn't flat ;)
Maurice On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i wasnt suggesting setting the user on request cycle, i was suggesting
keeping the id in session and letting requestcycle hold the cache for the request. i didnt realize websession has attach/detach, so this can be made simpler
MySession extends WebSession { private long userid; private transient User user; setUser(User u) { userid=u.getid(); user=u;
} getUser() { if (user==null) { user=loaduserbyid(userid); } return user; }
detach() { user=null; } -IgorOn 7/31/06, Maurice Marrink
[EMAIL PROTECTED] wrote:store is detached. second request comes in and it is dealing with stale dataunless you reload the user object. correct that is why you should use an imodel or come up with your own
attach detach strategy also storing imodel in session wont work because session doesnt have animodel slot so who is going to be responsible for detaching that model
atthe end of request? session has an onattach and ondetach method you can use. Also the way i understand how the whole requestcycle stuff happens
(and i know you guys know way more about that then me) is that a new requestcycleobject is created on every request by a factory so how is the current user supposed to get set on the requestcycle?
Don't get me wrong i am not criticizing you guys, i am just curious as to how the internals of wicket operate. Maurice
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:but we are talking about caching here. if you store the instance of
the useryou loaded in session that is fine for the request that loaded it. but whathappens after that request ends? the session is closed, the instance
youstore is detached. second request comes in and it is dealing with stale dataunless you reload the user object. also storing imodel in session wont work because session doesnt have
animodel slot so who is going to be responsible for detaching that model atthe end of request? -Igor
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote: true, but shouldn't the lock on the session prevent that in like 95%
of all the cases? Maurice On 7/31/06, Johan Compagner [EMAIL PROTECTED]
wrote:A session can be used by multiply threads/request So it will be detached by those when they are finished. So another request can be busy with it while another calls detach on
it. johanOn 7/31/06, Maurice Marrink
[EMAIL PROTECTED] wrote: i wouldn't recommend doing this in session because user entity will become detached, i would instead do it in the requestcycle so
the user is loaded once per request Yeah are you sure about this Igor? because we are also attaching our user object (hibernate object) to our session, lazy loading it
whenever needed. And we have not noticed it getting detached before the end of the request. Mats i guess this also answers your question
about if it is possible to put an imodel in the session. however if you are really concerned about the db access every time you could always store the team id in the session.
Maurice On 7/31/06, Mats Norén [EMAIL PROTECTED]
wrote: On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:i wouldnt recommend doint this in session because user entity
will becomedetached, i would instead do it in the requestcycle so the user is loaded
once per request It is? I've used a User-object in session and I haven't noticed that it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses the code below?
I think I saw an example (could have been in databinder) where a IModel was stored in session. Is that an alternative?
((MyRequestCycle)RequestCycle.get()).getUser();
Re: [Wicket-user] Authorization-question
in fact you dont need to do any caching, if you do loadbyid hibernate session (1st level cache) will cache it for you!-IgorOn 8/1/06, Igor Vaynberg
[EMAIL PROTECTED] wrote:
you dont store the object. store the id and load it on demand caching it for the duration of the request.-Igor
On 8/1/06, Maurice Marrink
[EMAIL PROTECTED] wrote:
Ok, so the session is not 100% safe for attaching detaching hibernate
stuff. If there is a better place to store something like a userobject i would love to here about it.MauriceOn 7/31/06, Johan Compagner
[EMAIL PROTECTED]
wrote: yes but with igors example it is possible that the session is used over multiply request we do have a lock But that lock doesn't lock globally over everything. So it is possible that it gets detached from under your nose. But that is
not a problem But it is also possible that you get a user loaded by another thread == hibernate session. Session.detach() is not called in a sync block... johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote: Glad to see it was just a misunderstanding. I was afraid you guys were
gonna tell me the world isn't flat ;)
Maurice On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i wasnt suggesting setting the user on request cycle, i was suggesting
keeping the id in session and letting requestcycle hold the cache for the request. i didnt realize websession has attach/detach, so this can be made simpler
MySession extends WebSession { private long userid; private transient User user; setUser(User u) { userid=u.getid(); user=u;
} getUser() { if (user==null) { user=loaduserbyid(userid); } return user; }
detach() { user=null; } -IgorOn 7/31/06, Maurice Marrink
[EMAIL PROTECTED] wrote:store is detached. second request comes in and it is dealing with stale dataunless you reload the user object. correct that is why you should use an imodel or come up with your own
attach detach strategy also storing imodel in session wont work because session doesnt have animodel slot so who is going to be responsible for detaching that model
atthe end of request? session has an onattach and ondetach method you can use. Also the way i understand how the whole requestcycle stuff happens
(and i know you guys know way more about that then me) is that a new requestcycleobject is created on every request by a factory so how is the current user supposed to get set on the requestcycle?
Don't get me wrong i am not criticizing you guys, i am just curious as to how the internals of wicket operate. Maurice
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:but we are talking about caching here. if you store the instance of
the useryou loaded in session that is fine for the request that loaded it. but whathappens after that request ends? the session is closed, the instance
youstore is detached. second request comes in and it is dealing with stale dataunless you reload the user object. also storing imodel in session wont work because session doesnt have
animodel slot so who is going to be responsible for detaching that model atthe end of request? -Igor
On 7/31/06, Maurice Marrink [EMAIL PROTECTED]
wrote: true, but shouldn't the lock on the session prevent that in like 95%
of all the cases? Maurice On 7/31/06, Johan Compagner
[EMAIL PROTECTED]
wrote:A session can be used by multiply threads/request So it will be detached by those when they are finished. So another request can be busy with it while another calls detach on
it. johanOn 7/31/06, Maurice Marrink
[EMAIL PROTECTED] wrote: i wouldn't recommend doing this in session because user entity
will become detached, i would instead do it in the requestcycle so
the user is loaded once per request Yeah are you sure about this Igor? because we are also attaching our user object (hibernate object) to our session, lazy loading it
whenever needed. And we have not noticed it getting detached before the end of the request. Mats i guess this also answers your question
about if it is possible to put an imodel in the session. however if you are really concerned about the db access every time you could always store the team id in the session.
Maurice On 7/31/06, Mats Norén
[EMAIL PROTECTED]
wrote: On 7/31/06, Igor Vaynberg [EMAIL PROTECTED]
wrote:i wouldnt recommend doint this in session because user entity
will becomedetached, i would instead do it in the requestcycle so the user is loaded
once per request It is? I've used a User-object in session and I haven't noticed that it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses the code below?
I think I saw an
Re: [Wicket-user] Authorization-question
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i wouldnt recommend doint this in session because user entity will become
detached, i would instead do it in the requestcycle so the user is loaded
once per request
It is? I've used a User-object in session and I haven't noticed that
it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses the code below?
I think I saw an example (could have been in databinder) where a
IModel was stored in session. Is that an alternative?
((MyRequestCycle)RequestCycle.get()).getUser();
MyRequestCycle {
private transient User user;
getuser() { if (user==null) { user=loaduser(session.get().getuserid()); }
onendrequest() { user=null; }
}
-Igor
/Mats
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Authorization-question
i wouldn't recommend doing this in session because user entity will
become detached, i would instead do it in the requestcycle so the
user is loaded once per request
Yeah are you sure about this Igor? because we are also attaching our
user object (hibernate object) to our session, lazy loading it
whenever needed. And we have not noticed it getting detached before
the end of the request. Mats i guess this also answers your question
about if it is possible to put an imodel in the session. however if
you are really concerned about the db access every time you could
always store the team id in the session.
Maurice
On 7/31/06, Mats Norén [EMAIL PROTECTED] wrote:
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i wouldnt recommend doint this in session because user entity will become
detached, i would instead do it in the requestcycle so the user is loaded
once per request
It is? I've used a User-object in session and I haven't noticed that
it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses the code
below?
I think I saw an example (could have been in databinder) where a
IModel was stored in session. Is that an alternative?
((MyRequestCycle)RequestCycle.get()).getUser();
MyRequestCycle {
private transient User user;
getuser() { if (user==null) { user=loaduser(session.get().getuserid()); }
onendrequest() { user=null; }
}
-Igor
/Mats
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Authorization-question
A session can be used by multiply threads/requestSo it will be detached by those when they are finished. So another request can be busy with it while another calls detach on it.johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
i wouldn't recommend doing this in session because user entity willbecome detached, i would instead do it in the requestcycle so theuser is loaded once per requestYeah are you sure about this Igor? because we are also attaching our
user object (hibernate object) to our session, lazy loading itwhenever needed. And we have not noticed it getting detached beforethe end of the request. Mats i guess this also answers your questionabout if it is possible to put an imodel in the session. however if
you are really concerned about the db access every time you couldalways store the team id in the session.MauriceOn 7/31/06, Mats Norén [EMAIL PROTECTED]
wrote: On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i wouldnt recommend doint this in session because user entity will become
detached, i would instead do it in the requestcycle so the user is loaded once per request It is? I've used a User-object in session and I haven't noticed that it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses the code below? I think I saw an example (could have been in databinder) where a IModel was stored in session. Is that an alternative?
((MyRequestCycle)RequestCycle.get()).getUser(); MyRequestCycle { private transient User user; getuser() { if (user==null) { user=loaduser(
session.get().getuserid()); } onendrequest() { user=null; } } -Igor /Mats -
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___
Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Authorization-question
true, but shouldn't the lock on the session prevent that in like 95%
of all the cases?
Maurice
On 7/31/06, Johan Compagner [EMAIL PROTECTED] wrote:
A session can be used by multiply threads/request
So it will be detached by those when they are finished.
So another request can be busy with it while another calls detach on it.
johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
i wouldn't recommend doing this in session because user entity will
become detached, i would instead do it in the requestcycle so the
user is loaded once per request
Yeah are you sure about this Igor? because we are also attaching our
user object (hibernate object) to our session, lazy loading it
whenever needed. And we have not noticed it getting detached before
the end of the request. Mats i guess this also answers your question
about if it is possible to put an imodel in the session. however if
you are really concerned about the db access every time you could
always store the team id in the session.
Maurice
On 7/31/06, Mats Norén [EMAIL PROTECTED] wrote:
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i wouldnt recommend doint this in session because user entity will
become
detached, i would instead do it in the requestcycle so the user is
loaded
once per request
It is? I've used a User-object in session and I haven't noticed that
it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses the
code below?
I think I saw an example (could have been in databinder) where a
IModel was stored in session. Is that an alternative?
((MyRequestCycle)RequestCycle.get()).getUser();
MyRequestCycle {
private transient User user;
getuser() { if (user==null) { user=loaduser(
session.get().getuserid()); }
onendrequest() { user=null; }
}
-Igor
/Mats
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Authorization-question
but we are talking about caching here. if you store the instance of the user you loaded in session that is fine for the request that loaded it. but what happens after that request ends? the session is closed, the instance you store is detached. second request comes in and it is dealing with stale data unless you reload the user object.
also storing imodel in session wont work because session doesnt have an imodel slot so who is going to be responsible for detaching that model at the end of request?-Igor
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
true, but shouldn't the lock on the session prevent that in like 95%of all the cases?MauriceOn 7/31/06, Johan Compagner [EMAIL PROTECTED] wrote:
A session can be used by multiply threads/request So it will be detached by those when they are finished. So another request can be busy with it while another calls detach on it. johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote: i wouldn't recommend doing this in session because user entity will
become detached, i would instead do it in the requestcycle so the user is loaded once per request Yeah are you sure about this Igor? because we are also attaching our user object (hibernate object) to our session, lazy loading it
whenever needed. And we have not noticed it getting detached before the end of the request. Mats i guess this also answers your question about if it is possible to put an imodel in the session. however if
you are really concerned about the db access every time you could always store the team id in the session. Maurice On 7/31/06, Mats Norén
[EMAIL PROTECTED] wrote: On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:i wouldnt recommend doint this in session because user entity will
becomedetached, i would instead do it in the requestcycle so the user is loadedonce per request It is? I've used a User-object in session and I haven't noticed that
it gets detached I guess I'll have to look into to that. Can I still have a getUser() method in Session that in turn uses the code below?
I think I saw an example (could have been in databinder) where a IModel was stored in session. Is that an alternative? ((MyRequestCycle)RequestCycle.get()).getUser();
MyRequestCycle {private transient User user; getuser() { if (user==null) { user=loaduser(
session.get().getuserid()); }onendrequest() { user=null; }} -Igor/Mats
- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net
's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user-
Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
Re: [Wicket-user] Authorization-question
store is detached. second request comes in and it is dealing with stale data
unless you reload the user object.
correct that is why you should use an imodel or come up with your own
attach detach strategy
also storing imodel in session wont work because session doesnt have an
imodel slot so who is going to be responsible for detaching that model at
the end of request?
session has an onattach and ondetach method you can use.
Also the way i understand how the whole requestcycle stuff happens
(and i know you guys know way more about that then me) is that a new
requestcycleobject is created on every request by a factory so how is
the current user supposed to get set on the requestcycle?
Don't get me wrong i am not criticizing you guys, i am just curious as
to how the internals of wicket operate.
Maurice
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
but we are talking about caching here. if you store the instance of the user
you loaded in session that is fine for the request that loaded it. but what
happens after that request ends? the session is closed, the instance you
store is detached. second request comes in and it is dealing with stale data
unless you reload the user object.
also storing imodel in session wont work because session doesnt have an
imodel slot so who is going to be responsible for detaching that model at
the end of request?
-Igor
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
true, but shouldn't the lock on the session prevent that in like 95%
of all the cases?
Maurice
On 7/31/06, Johan Compagner [EMAIL PROTECTED] wrote:
A session can be used by multiply threads/request
So it will be detached by those when they are finished.
So another request can be busy with it while another calls detach on it.
johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
i wouldn't recommend doing this in session because user entity will
become detached, i would instead do it in the requestcycle so the
user is loaded once per request
Yeah are you sure about this Igor? because we are also attaching our
user object (hibernate object) to our session, lazy loading it
whenever needed. And we have not noticed it getting detached before
the end of the request. Mats i guess this also answers your question
about if it is possible to put an imodel in the session. however if
you are really concerned about the db access every time you could
always store the team id in the session.
Maurice
On 7/31/06, Mats Norén [EMAIL PROTECTED] wrote:
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i wouldnt recommend doint this in session because user entity will
become
detached, i would instead do it in the requestcycle so the user is
loaded
once per request
It is? I've used a User-object in session and I haven't noticed that
it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses the
code below?
I think I saw an example (could have been in databinder) where a
IModel was stored in session. Is that an alternative?
((MyRequestCycle)RequestCycle.get()).getUser();
MyRequestCycle {
private transient User user;
getuser() { if (user==null) { user=loaduser(
session.get().getuserid()); }
onendrequest() { user=null; }
}
-Igor
/Mats
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net 's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
Re: [Wicket-user] Authorization-question
i wasnt suggesting setting the user on request cycle, i was suggesting keeping the id in session and letting requestcycle hold the cache for the request.i didnt realize websession has attach/detach, so this can be made simpler
MySession extends WebSession { private long userid; private transient User user; setUser(User u) { userid=u.getid(); user=u; } getUser() { if (user==null) {
user=loaduserbyid(userid); } return user; } detach() { user=null; }-IgorOn 7/31/06,
Maurice Marrink [EMAIL PROTECTED] wrote:
store is detached. second request comes in and it is dealing with stale data unless you reload the user object.correct that is why you should use an imodel or come up with your ownattach detach strategy
also storing imodel in session wont work because session doesnt have an imodel slot so who is going to be responsible for detaching that model at the end of request?session has an onattach and ondetach method you can use.
Also the way i understand how the whole requestcycle stuff happens(and i know you guys know way more about that then me) is that a newrequestcycleobject is created on every request by a factory so how is
the current user supposed to get set on the requestcycle?Don't get me wrong i am not criticizing you guys, i am just curious asto how the internals of wicket operate.MauriceOn 7/31/06, Igor Vaynberg
[EMAIL PROTECTED] wrote: but we are talking about caching here. if you store the instance of the user you loaded in session that is fine for the request that loaded it. but what
happens after that request ends? the session is closed, the instance you store is detached. second request comes in and it is dealing with stale data unless you reload the user object.
also storing imodel in session wont work because session doesnt have an imodel slot so who is going to be responsible for detaching that model at the end of request? -Igor
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote: true, but shouldn't the lock on the session prevent that in like 95% of all the cases?
Maurice On 7/31/06, Johan Compagner [EMAIL PROTECTED] wrote: A session can be used by multiply threads/request So it will be detached by those when they are finished.
So another request can be busy with it while another calls detach on it. johanOn 7/31/06, Maurice Marrink
[EMAIL PROTECTED] wrote: i wouldn't recommend doing this in session because user entity will become detached, i would instead do it in the requestcycle so the user is loaded once per request
Yeah are you sure about this Igor? because we are also attaching our user object (hibernate object) to our session, lazy loading it whenever needed. And we have not noticed it getting detached before
the end of the request. Mats i guess this also answers your question about if it is possible to put an imodel in the session. however if you are really concerned about the db access every time you could
always store the team id in the session. Maurice On 7/31/06, Mats Norén [EMAIL PROTECTED]
wrote:On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i wouldnt recommend doint this in session because user entity will
become detached, i would instead do it in the requestcycle so the user is loaded once per request It is? I've used a User-object in session and I haven't noticed that
it gets detached I guess I'll have to look into to that. Can I still have a getUser() method in Session that in turn uses the code below?
I think I saw an example (could have been in databinder) where aIModel was stored in session. Is that an alternative?((MyRequestCycle)RequestCycle.get()).getUser();
MyRequestCycle { private transient User user; getuser() { if (user==null) { user=loaduser(
session.get().getuserid()); } onendrequest() { user=null; } } -Igor
/Mats-Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net 's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Authorization-question
Glad to see it was just a misunderstanding. I was afraid you guys were
gonna tell me the world isn't flat ;)
Maurice
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i wasnt suggesting setting the user on request cycle, i was suggesting
keeping the id in session and letting requestcycle hold the cache for the
request.
i didnt realize websession has attach/detach, so this can be made simpler
MySession extends WebSession {
private long userid;
private transient User user;
setUser(User u) {
userid=u.getid();
user=u;
}
getUser() {
if (user==null) {
user=loaduserbyid(userid);
}
return user;
}
detach() {
user=null;
}
-Igor
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
store is detached. second request comes in and it is dealing with stale
data
unless you reload the user object.
correct that is why you should use an imodel or come up with your own
attach detach strategy
also storing imodel in session wont work because session doesnt have an
imodel slot so who is going to be responsible for detaching that model
at
the end of request?
session has an onattach and ondetach method you can use.
Also the way i understand how the whole requestcycle stuff happens
(and i know you guys know way more about that then me) is that a new
requestcycleobject is created on every request by a factory so how is
the current user supposed to get set on the requestcycle?
Don't get me wrong i am not criticizing you guys, i am just curious as
to how the internals of wicket operate.
Maurice
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
but we are talking about caching here. if you store the instance of the
user
you loaded in session that is fine for the request that loaded it. but
what
happens after that request ends? the session is closed, the instance you
store is detached. second request comes in and it is dealing with stale
data
unless you reload the user object.
also storing imodel in session wont work because session doesnt have an
imodel slot so who is going to be responsible for detaching that model
at
the end of request?
-Igor
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
true, but shouldn't the lock on the session prevent that in like 95%
of all the cases?
Maurice
On 7/31/06, Johan Compagner [EMAIL PROTECTED] wrote:
A session can be used by multiply threads/request
So it will be detached by those when they are finished.
So another request can be busy with it while another calls detach on
it.
johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote:
i wouldn't recommend doing this in session because user entity will
become detached, i would instead do it in the requestcycle so the
user is loaded once per request
Yeah are you sure about this Igor? because we are also attaching our
user object (hibernate object) to our session, lazy loading it
whenever needed. And we have not noticed it getting detached before
the end of the request. Mats i guess this also answers your question
about if it is possible to put an imodel in the session. however if
you are really concerned about the db access every time you could
always store the team id in the session.
Maurice
On 7/31/06, Mats Norén [EMAIL PROTECTED] wrote:
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i wouldnt recommend doint this in session because user entity
will
become
detached, i would instead do it in the requestcycle so the user
is
loaded
once per request
It is? I've used a User-object in session and I haven't noticed
that
it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses
the
code below?
I think I saw an example (could have been in databinder) where a
IModel was stored in session. Is that an alternative?
((MyRequestCycle)RequestCycle.get()).getUser();
MyRequestCycle {
private transient User user;
getuser() { if (user==null) { user=loaduser(
session.get().getuserid()); }
onendrequest() { user=null; }
}
-Igor
/Mats
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net 's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
Re: [Wicket-user] Authorization-question
yes but with igors example it is possiblethat the session is used over multiply request we do have a lockBut that lock doesn't lock globally over everything.So it is possible that it gets detached from under your nose. But that is not a problem
But it is also possible that you get a user loaded by another thread == hibernate session.Session.detach() is not called in a sync block...johanOn 7/31/06,
Maurice Marrink [EMAIL PROTECTED] wrote:
Glad to see it was just a misunderstanding. I was afraid you guys weregonna tell me the world isn't flat ;)MauriceOn 7/31/06, Igor Vaynberg [EMAIL PROTECTED]
wrote: i wasnt suggesting setting the user on request cycle, i was suggesting keeping the id in session and letting requestcycle hold the cache for the request. i didnt realize websession has attach/detach, so this can be made simpler
MySession extends WebSession {private long userid;private transient User user;setUser(User u) {userid=u.getid();user=u;}
getUser() { if (user==null) {user=loaduserbyid(userid); } return user; } detach() {user=null;
} -Igor On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote: store is detached. second request comes in and it is dealing with stale
data unless you reload the user object. correct that is why you should use an imodel or come up with your own attach detach strategyalso storing imodel in session wont work because session doesnt have an
imodel slot so who is going to be responsible for detaching that model at the end of request? session has an onattach and ondetach method you can use.
Also the way i understand how the whole requestcycle stuff happens (and i know you guys know way more about that then me) is that a new requestcycleobject is created on every request by a factory so how is
the current user supposed to get set on the requestcycle? Don't get me wrong i am not criticizing you guys, i am just curious as to how the internals of wicket operate.
Maurice On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote: but we are talking about caching here. if you store the instance of the
user you loaded in session that is fine for the request that loaded it. but what happens after that request ends? the session is closed, the instance you store is detached. second request comes in and it is dealing with stale
data unless you reload the user object. also storing imodel in session wont work because session doesnt have an imodel slot so who is going to be responsible for detaching that model
at the end of request? -IgorOn 7/31/06, Maurice Marrink
[EMAIL PROTECTED] wrote: true, but shouldn't the lock on the session prevent that in like 95% of all the cases? Maurice
On 7/31/06, Johan Compagner [EMAIL PROTECTED] wrote: A session can be used by multiply threads/requestSo it will be detached by those when they are finished.
So another request can be busy with it while another calls detach on it. johan
On 7/31/06, Maurice Marrink [EMAIL PROTECTED] wrote: i wouldn't recommend doing this in session because user entity will
become detached, i would instead do it in the requestcycle so the user is loaded once per request Yeah are you sure about this Igor? because we are also attaching our
user object (hibernate object) to our session, lazy loading it whenever needed. And we have not noticed it getting detached before the end of the request. Mats i guess this also answers your question
about if it is possible to put an imodel in the session. however if you are really concerned about the db access every time you could always store the team id in the session.
Maurice On 7/31/06, Mats Norén [EMAIL PROTECTED] wrote:
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i wouldnt recommend doint this in session because user entity
willbecome detached, i would instead do it in the requestcycle so the user isloaded once per request
It is? I've used a User-object in session and I haven't noticed that it gets detached I guess I'll have to look into to that.
Can I still have a getUser() method in Session that in turn uses thecode below? I think I saw an example (could have been in databinder) where a
IModel was stored in session. Is that an alternative?((MyRequestCycle)RequestCycle.get()).getUser();
MyRequestCycle { private transient User user; getuser() { if (user==null) { user=loaduser(
session.get().getuserid()); } onendrequest() { user=null; } } -Igor
/Mats
- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net 's Techsay panel and you'll get the chance to
shareyour opinions on IT business topics through brief surveys -- and earn cash
Re: [Wicket-user] Authorization-question
here is some pseudo code:class BaseTeamPage extends Webpage { private final long teamid; public long getteamid() { return teamid; } public BaseTeamPage(long teamid) { this.teamid=teamid
; }}isactionallowed(Component c, Action act) { if (act==Component.VISIBLE) { if (c.getPage()!=nullc.getPage() instanceof BaseTeamPage) { final BaseTeamPage page=
c.getPage(); long teamid=page.getteamid(); from here on you have the team id so you can do whateverhope it gets you started-Igor
On 7/30/06, Mats Norén [EMAIL PROTECTED] wrote:
Hi,I've got a scenario where I would like to filter rendering ofcomponents based on a users role but the roles change depending on apage parameter, ie:- PageA has a page parameter teamId- if the teamId is 1 the User is admin (for that particular team)
- if the teamId is 2 the User is an ordinary userEvery page in the application works in the same way.In my other attempts with wicket and authorization I used anAuthenticatedWebSession and annotations to filter the components but I
don't see how I can combine that with a page parameter?Any ideas?/Mats-Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Authorization-question
Ah, neat. OO to the rescue :)
On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
here is some pseudo code:
class BaseTeamPage extends Webpage {
private final long teamid;
public long getteamid() { return teamid; }
public BaseTeamPage(long teamid) {
this.teamid=teamid ;
}
}
Did you mean isActionAuthorized here?
From the IAuthorizationStrategy?
isactionallowed(Component c, Action act) {
if (act==Component.VISIBLE) {
if (c.getPage()!=nullc.getPage() instanceof BaseTeamPage) {
final BaseTeamPage page= c.getPage();
long teamid=page.getteamid(); from here on you have
the team id so you can do whatever
The problem is that I don't really see how I can get the different
roles associated with the User-object based on the teamId and get a
chance to compare them.
I'm guessing that the isActionAuthorized(Component comp, Action act)
gets called on every component render and I don't want to hit my db
(although I'm using Hibernate and it's cache) every time I render a
component.
Is it safe to get the User-object from the session via the page?
My current implementation of a user object is actually a Person-object:
Person
SetTeamPerson teamPersons;
TeamPerson
SetTeamPersonRole roles;
TeamPersonRole
id
name
Is there a way I can use to extend/use the annotation-approach? Or
mabye combine the two?
I'm guessing that there will eventually be a mixture of pages that
depend on a team and pages that are for every team so to speak.
Btw, thanks for the quick reply! :)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Authorization-question
i wouldnt recommend doint this in session because user entity will become detached, i would instead do it in the requestcycle so the user is loaded once per request((MyRequestCycle)RequestCycle.get()).getUser();
MyRequestCycle { private transient User user; getuser() { if (user==null) { user=loaduser(session.get().getuserid()); } onendrequest() { user=null; }}-Igor
On 7/30/06, Mats Norén [EMAIL PROTECTED] wrote:
Ah, neat. OO to the rescue :)On 7/31/06, Igor Vaynberg [EMAIL PROTECTED] wrote: here is some pseudo code: class BaseTeamPage extends Webpage {
private final long teamid; public long getteamid() { return teamid; } public BaseTeamPage(long teamid) { this.teamid=teamid ;} }
Did you mean isActionAuthorized here?From the IAuthorizationStrategy? isactionallowed(Component c, Action act) { if (act==Component.VISIBLE) {if (
c.getPage()!=nullc.getPage() instanceof BaseTeamPage) {final BaseTeamPage page= c.getPage();long teamid=page.getteamid(); from here on you have the team id so you can do whatever
The problem is that I don't really see how I can get the differentroles associated with the User-object based on the teamId and get achance to compare them.I'm guessing that the isActionAuthorized(Component comp, Action act)
gets called on every component render and I don't want to hit my db(although I'm using Hibernate and it's cache) every time I render acomponent.Is it safe to get the User-object from the session via the page?
My current implementation of a user object is actually a Person-object:Person SetTeamPerson teamPersons;TeamPerson SetTeamPersonRole roles;TeamPersonRole id
nameIs there a way I can use to extend/use the annotation-approach? Ormabye combine the two?I'm guessing that there will eventually be a mixture of pages thatdepend on a team and pages that are for every team so to speak.
Btw, thanks for the quick reply! :)-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
