[ASP.NET] How to create multiple sessions for a single visitor for different tab?

[sowen]

hi, I know this question sounds weird. But if there is no easy way to
retrieve the tab index, what would be a possible way to create a
different session for a different tab, even though internally they are
still one session, but with a "tab-index" as part of the session key,
the user is able to browse the same page without data conflict.

any sparkle is appreciated. thanks!

[Andrew Badera]

ok, yeah, asp.net? you didn't specify. when you said .net previously, I assumed you meant a desktop client.

For the most part, you can never interact with a browser from a server, beyond displaying page content and associated stuff there. ActiveX/Mozilla ActiveX would in fact be required for that, I don't think XPCOM would have been a solution. That said, you might be able ??? to get the tab index using JavaScript, and report it back to the server, whether through a conventional postback, AJAX, whatever.

I'm not understanding the nature of the conflict you're looking to avoid here, could you provide more detail? You can always generate a key for a page on non-postback page loads, and use that key for objects stored in the session ....

--
--Andy Badera
http://andrew.badera.us/ http://flipbitsnotburgers.blogspot.com/
and...@badera.us
(518) 641-1280
Google me: http://www.google.com/search?q=andrew+badera

[sowen]

yes, this is ASP.NET, I thought I put it in the title, sorry.

I didn't mean I want to get the tab id, I was just using that as an
example.

The problem is we are using server-side viewstate and store it in the
session, but it doesn't work in multi-browsers.
if one user opens two browsers and do the post-back to a same page,
the session (viewstate) will have conflict if we query the session
with the key directly.

what we want is having another unique identifier for a different
window (tab) as part of the key.
for ie6, it's really easy, just use the window handler + the session
key; but firefox and ie7 are just not that easy.

other than that, we are also seeking some other ideas; in the
meantime, i just post that question here and see if anyone else can
bring a sparkle. :)

On Apr 14, 3:48 pm, "Andrew Badera" <and...@badera.us> wrote:
> ok, yeah, asp.net? you didn't specify. when you said .net previously, I
> assumed you meant a desktop client.
>
> For the most part, you can never interact with a browser from a server,
> beyond displaying page content and associated stuff there. ActiveX/Mozilla
> ActiveX would in fact be required for that, I don't think XPCOM would have
> been a solution. That said, you might be able ??? to get the tab index using
> JavaScript, and report it back to the server, whether through a conventional
> postback, AJAX, whatever.
>
> I'm not understanding the nature of the conflict you're looking to avoid
> here, could you provide more detail? You can always generate a key for a
> page on non-postback page loads, and use that key for objects stored in the
> session ....
>

> On Mon, Apr 14, 2008 at 4:32 PM, sowen <sowenche...@gmail.com> wrote:
>
> > hi, I know this question sounds weird. But if there is no easy way to
> > retrieve the tab index, what would be a possible way to create a
> > different session for a different tab, even though internally they are
> > still one session, but with a "tab-index" as part of the session key,
> > the user is able to browse the same page without data conflict.
>
> > any sparkle is appreciated. thanks!
>
> --

> --Andy Baderahttp://andrew.badera.us/http://flipbitsnotburgers.blogspot.com/

[Andrew Badera]

Your pages should be atomic and stateless as possible. Postbacks should be idempotent as much and as frequently as possible.

Using Session has generally never been the best of ideas. Is it absolutely necessary in your architecture, or is it a necessity you've imposed on yourselves?

--
--Andy Badera
http://andrew.badera.us/ http://flipbitsnotburgers.blogspot.com/

[Andrew Badera]

Also, what is motivating your users to open all these browsers, browser windows, tabs? Or are you just trying to prepare for all possibilities?

[Joe Enos]

You've just been waiting to use that word, haven't you? I saw that it
was your new favorite word...

> > > --Andy Baderahttp://
> > andrew.badera.us/http://flipbitsnotburgers.blogspot.com/
> > > and...@badera.us

> > > (518) 641-1280
> > > Google me:http://www.google.com/search?q=andrew+badera
>
> --
> --Andy Baderahttp://andrew.badera.us/http://flipbitsnotburgers.blogspot.com/
> and...@badera.us
> (518) 641-1280

> Google me:http://www.google.com/search?q=andrew+badera- Hide quoted text -
>
> - Show quoted text -

[Andrew Badera]

bwahahahha you can bet your bottom dollar I was poised and ready :)

It's so perfect in the web & service world though.

[sowen]

because this is a huge system, we have to prepare all kind of
different users' behavior

whether to use Session is a different topic, the important thing is
where to store ViewState in server-side. Even the Microsoft its own
Session ViewState control doesn't support the multiple browsers
either. We can certainly later on change the Session to anything else,
but that will be the same. How to query the ViewState is the key. If
we set ViewState["var1"] = "hello" in window A, then in window B, when
we get ViewState["var1"] will be hello too.

that's something we are trying to solve.

On Apr 14, 4:11 pm, "Andrew Badera" <and...@badera.us> wrote:
> Also, what is motivating your users to open all these browsers, browser
> windows, tabs? Or are you just trying to prepare for all possibilities?
>
> On Mon, Apr 14, 2008 at 5:10 PM, Andrew Badera <and...@badera.us> wrote:
> > Your pages should be atomic and stateless as possible. Postbacks should be
> > idempotent as much and as frequently as possible.
>
> > Using Session has generally never been the best of ideas. Is it absolutely
> > necessary in your architecture, or is it a necessity you've imposed on
> > yourselves?
>

[sowen]

by the way, in deed, supporting multiple browsers in the system is a
user-requirement, we can do nothing but support this stupid idea.

and we cannot develop our own browser either, blab blab blab, that's
the sad world

On Apr 14, 4:11 pm, "Andrew Badera" <and...@badera.us> wrote:
> Also, what is motivating your users to open all these browsers, browser
> windows, tabs? Or are you just trying to prepare for all possibilities?
>
> On Mon, Apr 14, 2008 at 5:10 PM, Andrew Badera <and...@badera.us> wrote:
> > Your pages should be atomic and stateless as possible. Postbacks should be
> > idempotent as much and as frequently as possible.
>
> > Using Session has generally never been the best of ideas. Is it absolutely
> > necessary in your architecture, or is it a necessity you've imposed on
> > yourselves?
>

[Andrew Badera]

Let's clarify .. are we really talking multiple browsers as in IE, FF, Opera, Safari (which last I knew, this situation should initiate multiple sessions) or multiple instances of a single browser, where things get more mushy?

[sowen]

sorry, haha, indeed my word was confusing.

I meant when a user opens multiple tabs in FF, or in IE7, or in opera,
the server-side viewstate will fail

I am not saying a user opens one FF, one IE7, and one opera, etc.

On Apr 14, 4:22 pm, "Andrew Badera" <and...@badera.us> wrote:
> Let's clarify .. are we really talking multiple browsers as in IE, FF,
> Opera, Safari (which last I knew, this situation should initiate multiple
> sessions) or multiple instances of a single browser, where things get more
> mushy?
>

[Andrew Badera]

In that case, your pages really need to be as atomic and idempotent as possible. Could you provide an example of the problems (I can imagine plenty, but something specific would help) you're dealing with? And I'll ask again, is Session truly necessary, or did you/your team make it a necessity.

--
--Andy Badera

[sowen]

as I said, this is not about Session. Session is just the easiest way
can be used as a storage example at this point. It's about how we
query the server-side viewstate and return the value.

It's difficult for me to post some code here. but the main reason is,
there are many pages in our system dealing with complicated database
entity (parent-children etc.), to improve performance, we place the
entity in ViewState, then use lazy binding to bind child items.

For example, when a user wants to create a new record, open the pages,
a blank entity is created and is placed in the ViewState, then after
fill out all forms (some forms might not have to be opened, in that
case, the child-entity can be null), when the user clicks save, the
program will go through the entity and persist.

say, at the same time, the same user opens another window to search an
existing record on the same page, he opens a few sub-items, so all
opened entities are in the viewstate, other are not (coz it's lazy-
binding), then we are going to have a viewstate conflict, one is brand-
new, another has data from an existing record.

now, the user clicks save to persist the new record. it blows out.

so, single window, our structure works well; in IE6, it's easy to work
around; in tabs, there will be a big issue.

what I am looking for is, find a way to identify the user current
working instance( window or tab), and create another server-side
viewstate entry for that specific page.

On Apr 14, 4:51 pm, "Andrew Badera" <and...@badera.us> wrote:
> In that case, your pages really need to be as atomic and idempotent as
> possible. Could you provide an example of the problems (I can imagine
> plenty, but something specific would help) you're dealing with? And I'll ask

> again, is Session truly necessary, or did you/your team *make *it a

> --Andy Baderahttp://andrew.badera.us/http://flipbitsnotburgers.blogspot.com/

[Cerebrus]

No problem ! My postbacks have got Viagra ! ;-)

[Andrew Badera]

And that's exactly what I'm telling you: atomic and idempotent. If you're talking about ViewState in order to populate controls, the page should never care which instance it's being used by.

That, or I'm completely, totally misunderstanding you. If you don't have to worry about competing or racing Session or ViewState values, then why should the page ever care? If it's populating from the DB, it should, as a stateless medium, completely self-construct.

[Andrew Badera]

Can you hear me groaning, over here 'cross Ye Olde Ponde? That's not just the muscle I pulled half-sleeping on the couch last night.