Where to Cache "per user" Data That Can Get Updated By Admins

[Guadala Harry]

Is there any way for one Session to remove and update objects in another
Session? I seriously doubt it, but thought I'd ask. Here's why: I have some
data that is unique per user (or per session - similar to "welcome back,
Jim" after Jim logs in) and consumed across multiple pages. This "per user"
data lives in a database, so toward improving runtime performance I want to
cache data supporting this and similar per user features. Because the data
changes per user, output caching the page is out (at least I don't want to
cache per Custom right now). So, I'm looking at storing this per-user data
in either the Cache object or in Session state.

I think Session state would normally be the obvious choice - however - one
more important consideration that throws a wrench into that conventional
wisdom is that I need to let administrators of this application modify this
"per user" data - perhaps while users are online... so if the data is stored
in session, then the user would not get the new data until they establish a
new session... so now storing this data in the Cache seems to make sense
because it's relatively easy for any session to remove/update data in the
Cache.

So, given the requirements as described (and my somewhat limited knowledge
of ASP.NET), am I correct to conclude that this data should go into the
Cache and not Session? Are there alternatives to Cache and Session that
would make sense for this scenario?

Thanks!

[Patrice]

Yes (won't matter anyway if you shield this implementation detail from your
app by using an intermediate class). That said the requirement of having
those data updated by an admin while users are offline is reather unusual.
Is it really impossible to have this handled properly (you shouldn't store
data in the cache when they are not needed, it shouldn't be updated
directly).

Patrice

--

"Guadala Harry" <GM**@NoSpam.com> a écrit dans le message de
news:er**************@TK2MSFTNGP12.phx.gbl...

Is there any way for one Session to remove and update objects in another
Session? I seriously doubt it, but thought I'd ask. Here's why: I have some data that is unique per user (or per session - similar to "welcome back,
Jim" after Jim logs in) and consumed across multiple pages. This "per user" data lives in a database, so toward improving runtime performance I want to cache data supporting this and similar per user features. Because the data
changes per user, output caching the page is out (at least I don't want to
cache per Custom right now). So, I'm looking at storing this per-user data
in either the Cache object or in Session state.

I think Session state would normally be the obvious choice - however - one
more important consideration that throws a wrench into that conventional
wisdom is that I need to let administrators of this application modify this "per user" data - perhaps while users are online... so if the data is stored in session, then the user would not get the new data until they establish a new session... so now storing this data in the Cache seems to make sense
because it's relatively easy for any session to remove/update data in the
Cache.

So, given the requirements as described (and my somewhat limited knowledge
of ASP.NET), am I correct to conclude that this data should go into the
Cache and not Session? Are there alternatives to Cache and Session that
would make sense for this scenario?

Thanks!

[Guadala Harry]

Patrice,

Thanks for the response.

FWIW: rather unusual requirements happen all the time (that's why they pay
us the big bucks! - right!?)... and their presence and associated unusual
solutions don't necessarily imply that anything is being done improperly.
While I was somewhat vague in my OP, think about an app with security: an
admin can go in and modifies per-user permissions on something while users
are logged in. I currently have a security "gate keeper" class that will
ultimately provide up-to-the-nonosecond security - making the cached data
not so critical. But I'd like to make the user's experience a bit easier in
the case of such an unlikely scenario in which a user logs on and can access
something, and while the user is logged in, and admin comes in and changes
permissions on what that user can access. I'm just going the extra mile and
modifying what the user can see (which is cached as described in the OP)
before they get blocked by the security class. Just trynig to make the
user's experience a bit easier. I hope this makes sense.

Cheers!
"Patrice" <no****@nowhere.com> wrote in message
news:eB**************@TK2MSFTNGP11.phx.gbl...

Yes (won't matter anyway if you shield this implementation detail from your app by using an intermediate class). That said the requirement of having
those data updated by an admin while users are offline is reather unusual.
Is it really impossible to have this handled properly (you shouldn't store
data in the cache when they are not needed, it shouldn't be updated
directly).

Patrice

--

"Guadala Harry" <GM**@NoSpam.com> a écrit dans le message de
news:er**************@TK2MSFTNGP12.phx.gbl...

Is there any way for one Session to remove and update objects in another
Session? I seriously doubt it, but thought I'd ask. Here's why: I have some

data that is unique per user (or per session - similar to "welcome back,
Jim" after Jim logs in) and consumed across multiple pages. This "per

user"

data lives in a database, so toward improving runtime performance I want

to

cache data supporting this and similar per user features. Because the data changes per user, output caching the page is out (at least I don't want to cache per Custom right now). So, I'm looking at storing this per-user data in either the Cache object or in Session state.

I think Session state would normally be the obvious choice - however - one more important consideration that throws a wrench into that conventional
wisdom is that I need to let administrators of this application modify

this

"per user" data - perhaps while users are online... so if the data is

stored

in session, then the user would not get the new data until they establish a

new session... so now storing this data in the Cache seems to make sense
because it's relatively easy for any session to remove/update data in

the Cache.

So, given the requirements as described (and my somewhat limited knowledge of ASP.NET), am I correct to conclude that this data should go into the
Cache and not Session? Are there alternatives to Cache and Session that
would make sense for this scenario?

Thanks!

[Patrice]

More precisely I wanted to stress that IMO those data shouldn't be updated
"directly" in the "user store" (even a cache). Instead changes should be
"posted" to the database and the control flow of the user page should take
care of reloading those data in the (expired) cache.

Anyway from a non technical point of view, I would still consider to take
these changes into account the next time the user logs. In particular it
could be quite annoying for users to see options appearing or disappearing
while they are working especially if the admin performs multiple changes (in
which case using the session is enough).

If for some reason you want to take this change immediately into account,
you'll have just to expire the cache and the user control flow will take
care of loading new data into the cache...

Patrice

--

"Guadala Harry" <GM**@NoSpam.com> a écrit dans le message de
news:OX**************@tk2msftngp13.phx.gbl...

Patrice,

Thanks for the response.

FWIW: rather unusual requirements happen all the time (that's why they pay
us the big bucks! - right!?)... and their presence and associated unusual
solutions don't necessarily imply that anything is being done improperly.
While I was somewhat vague in my OP, think about an app with security: an
admin can go in and modifies per-user permissions on something while users
are logged in. I currently have a security "gate keeper" class that will
ultimately provide up-to-the-nonosecond security - making the cached data
not so critical. But I'd like to make the user's experience a bit easier in the case of such an unlikely scenario in which a user logs on and can access something, and while the user is logged in, and admin comes in and changes
permissions on what that user can access. I'm just going the extra mile and modifying what the user can see (which is cached as described in the OP)
before they get blocked by the security class. Just trynig to make the
user's experience a bit easier. I hope this makes sense.

Cheers!
"Patrice" <no****@nowhere.com> wrote in message
news:eB**************@TK2MSFTNGP11.phx.gbl...

Yes (won't matter anyway if you shield this implementation detail from your

app by using an intermediate class). That said the requirement of having
those data updated by an admin while users are offline is reather unusual.

Is it really impossible to have this handled properly (you shouldn't store data in the cache when they are not needed, it shouldn't be updated
directly).

Patrice

--

"Guadala Harry" <GM**@NoSpam.com> a écrit dans le message de
news:er**************@TK2MSFTNGP12.phx.gbl...

Is there any way for one Session to remove and update objects in another Session? I seriously doubt it, but thought I'd ask. Here's why: I have

some

data that is unique per user (or per session - similar to "welcome back, Jim" after Jim logs in) and consumed across multiple pages. This "per

user"

data lives in a database, so toward improving runtime performance I want

to

cache data supporting this and similar per user features. Because the

data changes per user, output caching the page is out (at least I don't

want to cache per Custom right now). So, I'm looking at storing this per-user data in either the Cache object or in Session state.

I think Session state would normally be the obvious choice - however - one more important consideration that throws a wrench into that

conventional wisdom is that I need to let administrators of this application modify

this

"per user" data - perhaps while users are online... so if the data is

stored

in session, then the user would not get the new data until they

establish

a

new session... so now storing this data in the Cache seems to make sense because it's relatively easy for any session to remove/update data in

the Cache.

So, given the requirements as described (and my somewhat limited knowledge of ASP.NET), am I correct to conclude that this data should go into the Cache and not Session? Are there alternatives to Cache and Session that would make sense for this scenario?

Thanks!

[Brad Roberts]

What about putting " " in the span instead of text?

"Patrice" wrote:

More precisely I wanted to stress that IMO those data shouldn't be updated
"directly" in the "user store" (even a cache). Instead changes should be
"posted" to the database and the control flow of the user page should take
care of reloading those data in the (expired) cache.

Anyway from a non technical point of view, I would still consider to take
these changes into account the next time the user logs. In particular it
could be quite annoying for users to see options appearing or disappearing
while they are working especially if the admin performs multiple changes (in
which case using the session is enough).

If for some reason you want to take this change immediately into account,
you'll have just to expire the cache and the user control flow will take
care of loading new data into the cache...

Patrice

--

"Guadala Harry" <GM**@NoSpam.com> a écrit dans le message de
news:OX**************@tk2msftngp13.phx.gbl...

Patrice,

Thanks for the response.

FWIW: rather unusual requirements happen all the time (that's why they pay
us the big bucks! - right!?)... and their presence and associated unusual
solutions don't necessarily imply that anything is being done improperly.
While I was somewhat vague in my OP, think about an app with security: an
admin can go in and modifies per-user permissions on something while users
are logged in. I currently have a security "gate keeper" class that will
ultimately provide up-to-the-nonosecond security - making the cached data
not so critical. But I'd like to make the user's experience a bit easier

in

the case of such an unlikely scenario in which a user logs on and can

access

something, and while the user is logged in, and admin comes in and changes
permissions on what that user can access. I'm just going the extra mile

and

modifying what the user can see (which is cached as described in the OP)
before they get blocked by the security class. Just trynig to make the
user's experience a bit easier. I hope this makes sense.

Cheers!
"Patrice" <no****@nowhere.com> wrote in message
news:eB**************@TK2MSFTNGP11.phx.gbl...

Yes (won't matter anyway if you shield this implementation detail from

your

app by using an intermediate class). That said the requirement of having
those data updated by an admin while users are offline is reather unusual. Is it really impossible to have this handled properly (you shouldn't store data in the cache when they are not needed, it shouldn't be updated
directly).

Patrice

--

"Guadala Harry" <GM**@NoSpam.com> a écrit dans le message de
news:er**************@TK2MSFTNGP12.phx.gbl...
> Is there any way for one Session to remove and update objects in another > Session? I seriously doubt it, but thought I'd ask. Here's why: I have
some
> data that is unique per user (or per session - similar to "welcome back, > Jim" after Jim logs in) and consumed across multiple pages. This "per
user"
> data lives in a database, so toward improving runtime performance I want to
> cache data supporting this and similar per user features. Because the

data

> changes per user, output caching the page is out (at least I don't want

to

> cache per Custom right now). So, I'm looking at storing this per-user

data

> in either the Cache object or in Session state.
>
> I think Session state would normally be the obvious choice - however -

one

> more important consideration that throws a wrench into that

conventional > wisdom is that I need to let administrators of this application modify
this
> "per user" data - perhaps while users are online... so if the data is
stored
> in session, then the user would not get the new data until they

establish

a
> new session... so now storing this data in the Cache seems to make sense > because it's relatively easy for any session to remove/update data in

the

> Cache.
>
> So, given the requirements as described (and my somewhat limited

knowledge

> of ASP.NET), am I correct to conclude that this data should go into the > Cache and not Session? Are there alternatives to Cache and Session that > would make sense for this scenario?
>
> Thanks!
>
>