Microsoft Content Management Server - Passing posting from one CMSHttpContext to another

Author

Passing posting from one CMSHttpContext to another

Utunga

2006-11-24, 7:17 pm

Using CMS2002 SP2.

Here's the scenario.

1. We do some sort of (expensive) query to return an array of Posting
objects.
2. We want to cache that array of objects - in the Page.Cache memory -
with the query itself as the key for that array.
3. Each Posting in the array has a Posting.Context, of course, where
the context = the context of the user that executed the query.
4. I've assumed that its impossible to pass a posting, created by the
context belonging to user A in session A, to another user having
Context B. Is that true?

I guess I'm trying to choose between...

1. Just putting the posting object(s) directly in the Page.Cache and
seeing what happens when we pass from one user to the other (I will try
this, but thought I might ask for opinions on the wisdom of this, in
case it works).

2. Storing each Posting's PostingGuid in the Cache and retrieving that
within each new users context via Context.Searches.GetByGuid() which
seems to be the fastest way (and what we have been doing so far).

3. Doing everything using an Application Context and as a single user.

The problem with 2, is that (a) we have to re-retrieve that actual
posting object and (b) our business logic would be much easier if we
could introduce an "Article" object where there may be multiple
postings per Article.. and keeping track of all the potential guids
gets messed up. This is what we do now, sort of, and we get lots of
(bad) exceptions when we try to follow posting.ConnectedPostings in
various exception cases.

The problem with 3, is that its nice to do stuff using the current user
so as to (a) avoid admin users/passwords in a config file somewhere and
(b) it would be great to be able to see hey - this posting == null so
this user doesn't have permission to this posting.

The problem with 1 is that, well its probably the nicest, but what
happens when you pass a posting that is permissioned for user a to user
b that doesnt have permission to that posting? I guess it probably all
goes 'orribly wrong, but not sure what happens.

Thinking out loud really. Has anyone struck this kind of thing before?

Any suggestions and thanks in advance.

Miles

Stefan Goßner [MSFT]

2006-11-27, 7:20 am

Hi Utunga,

you are not allowed to keep any object beyond the scope of a single call.
This will separate the managed object from it's RCW (runtime com wrapper).
With other words: you will get expections.

You can't
- store postings in session variables
- store postings in application variables
- store postings in cache objects for a timeframe or a scope that exeeds the
current request.

What you can do is to either store the GUIDs or other properties inside the
cache.

Cheers,
Stefan

"Utunga" <utunga@gmail.com> wrote in message
news:1164415290.582961.316060@h54g2000cwb.googlegroups.com...
> Using CMS2002 SP2.
>
> Here's the scenario.
>
> 1. We do some sort of (expensive) query to return an array of Posting
> objects.
> 2. We want to cache that array of objects - in the Page.Cache memory -
> with the query itself as the key for that array.
> 3. Each Posting in the array has a Posting.Context, of course, where
> the context = the context of the user that executed the query.
> 4. I've assumed that its impossible to pass a posting, created by the
> context belonging to user A in session A, to another user having
> Context B. Is that true?
>
> I guess I'm trying to choose between...
>
> 1. Just putting the posting object(s) directly in the Page.Cache and
> seeing what happens when we pass from one user to the other (I will try
> this, but thought I might ask for opinions on the wisdom of this, in
> case it works).
>
> 2. Storing each Posting's PostingGuid in the Cache and retrieving that
> within each new users context via Context.Searches.GetByGuid() which
> seems to be the fastest way (and what we have been doing so far).
>
> 3. Doing everything using an Application Context and as a single user.
>
> The problem with 2, is that (a) we have to re-retrieve that actual
> posting object and (b) our business logic would be much easier if we
> could introduce an "Article" object where there may be multiple
> postings per Article.. and keeping track of all the potential guids
> gets messed up. This is what we do now, sort of, and we get lots of
> (bad) exceptions when we try to follow posting.ConnectedPostings in
> various exception cases.
>
> The problem with 3, is that its nice to do stuff using the current user
> so as to (a) avoid admin users/passwords in a config file somewhere and
> (b) it would be great to be able to see hey - this posting == null so
> this user doesn't have permission to this posting.
>
> The problem with 1 is that, well its probably the nicest, but what
> happens when you pass a posting that is permissioned for user a to user
> b that doesnt have permission to that posting? I guess it probably all
> goes 'orribly wrong, but not sure what happens.
>
> Thinking out loud really. Has anyone struck this kind of thing before?
>
> Any suggestions and thanks in advance.
>
> Miles
>