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
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
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,
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
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
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
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
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
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
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
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
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
Hi,
I've got a scenario where I would like to filter rendering of
components based on a users role but the roles change depending on a
page 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
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
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) {
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) {
16 matches
Mail list logo
