Re: overlapping R/Rs in same session
Re: overlapping R/Rs in same session
- Subject: Re: overlapping R/Rs in same session
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Wed, 21 Aug 2024 19:20:57 -0400
If you open a second tab, using cookies, they are shared.
If you continue doing more than 30 actions or so in the second tab, and then
later try to do 1 action in the first tab, it will break. The first tab will
try to do something but the page is out of the backtrack cache already.
Last tab wins.
> On Aug 21, 2024, at 6:55 AM, OCsite <email@hidden> wrote:
>
> Aaron,
>
>> On 21. 8. 2024, at 1:16, Aaron Rosenzweig <email@hidden> wrote:
>> Sounds like maybe your session is in the URL?
>
> Nope, we store them in cookies.
>
>> What if you put the session in a cookie? Then it’s not possible to have
>> multiple tabs in the same browser. The last tab wins.
>
> Alas, that's not how the browser works. Pretty often, e.g., if one opens a
> link by shift-cmd-click in a new tab, and in other cases too, more
> tabs/windows simply share the same wosid cookie, i.e., the same session.
>
> Myself I use Safari exclusively, but based on
> https://stackoverflow.com/questions/49687204/same-browser-but-different-windows-do-they-share-cookies
>
> <https://stackoverflow.com/questions/49687204/same-browser-but-different-windows-do-they-share-cookies>
> it seems it is a customary behaviour in other browsers, too.
>
> Thanks,
> OC
>
>>
>>> On Aug 19, 2024, at 9:25 AM, ocs--- via Webobjects-dev
>>> <email@hidden <mailto:email@hidden>>
>>> wrote:
>>>
>>> Hi there,
>>>
>>> looks like the main cause of those overlapping R/Rs which we ar clashing
>>> with lately is that some users just open their session in more windows or
>>> tabs, and work concurrently in those. Sigh.
>>>
>>> It's self-evident why it is a pretty bad idea from the technical POV, but I
>>> am afraid we can't explain it to plain users. Worse, if we found a way to
>>> prevent that (offhand, I am not sure whether it is technically possible,
>>> but even if so), I am afraid the users would complain that they simply
>>> insist on this terrible approach.
>>>
>>> Now though they complain some operations are “inexplicably” slow: “I
>>> understand that operation A which I've launched in one of my windows is
>>> complicated and thus takes many seconds, that's OK. But at the same moment
>>> I've launched an operation B in another of my windows; operation B is
>>> trivial and should be lightning fast, but it took an eternity! Fix your
>>> broken application!“
>>>
>>> Well you twit, op B took an eternity since it first waited many seconds
>>> until the slow op A you yourself launched in the same session finished;
>>> after that, A took about 100 ms of its own time. But this kind of
>>> explanation would not do with plain users at all :(
>>>
>>> Could anybody see any practical solution?
>>>
>>> Note please that making _all_ R/R lightning fast is practically impossible
>>> (we would have to refactor too heavily, not an option in a near future).
>>> Besides I am afraid even if we somehow succeeded to make all R/R reliably
>>> belong a second or so, they would still launch ten second-long operations
>>> in ten windows plus one 100 ms in another, and then complain that the last
>>> one took seconds too :(
>>>
>>> At this moment about the only solution very ugly work-around I can think of
>>> would be to choose a couple of the trivial operations whose speed the users
>>> consider most important, and re-write them without session (they would
>>> still need to work with the session ID, but important things like the
>>> current user etc. would have to be cached in the application in some kind
>>> of static map without using the Session instance at all). Sigh. Darn
>>> complex, but still worlds easier than attempting to make _all_ R/Rs
>>> 100ms-or-less...
>>>
>>> Any better idea?
>>>
>>> Thanks and all the best,
>>> OC
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden
>>> <mailto:email@hidden>)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>>
>>> This email sent to email@hidden
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden