WebSessionManager>>activeSessions

Can anyone explain activeSessions to me?  I mean, it seems like that would be, well, the active sessions connected?  But when I close all my browsers and tell the WebSessionManager to removeAllSessions, the activeSessions remain, and yet nothing is connected...?

It SEEMS like if you really wanted to clean up at night, you could remove these [activeSessions] as well?

Is this because I can't release the object created in the SwazooAida>>demoStart?

Just trying to understand the resources created and used a little better...

Out of curiosity: Why do you use

       activeSessions copy keys

instead of

       activeSessions keys copy

or even just

       activeSessions keys ?

I'd expect the latter to be cheaper, since you're only duplicating
the keys (if at all) and not the sessions.

Even simpler would be just to call #initActiveSessions :)

But removing all sessions is not very user friendly practice because (as you said) you logoff users too. It is better (and just good enough) to remove only anonymous (guest) sessions but on the other hand cleanup all presentation state by removing all Apps. And we just achieved that in a separate mail :)

Depending on what activeSessions is and how it or its method keys is
implemented, the first snippet above might even be in this category.

A "normal" shallow copy of an object allocates a new memory block
with enough room for the object's local storage, i.e. instance
variables. These are then copied over to the new place.

As instance variables typically are just references to other objects,
you end up copying references, not objects.

Time for a little experiment:

Object subclass: #Registry
       instanceVariables: 'dict'

Registry>>initialize
       dict := Dictionary new

Object subclass: #RegistryUser
       instanceVariables: 'reg'

RegistryUser>>initialize
       reg := Registry new

RegistryUser>>registry
       ^ reg

user1 := RegistryUser new reg.
user2 := RegistryUser new reg.
user3 := user1 copy.

With this setup, guess and print the results of:

       user1 = user2
       user2 = user3
       user1 = user3
       user1 == user3
       user1 registry = user2 registry
       user1 registry = user3 registry
       user1 registry == user3 registry

On Mon, 9 Jun 2008 07:35:21 -0400

"Rob Rothwell" <[hidden email]> wrote:

> Did you mean

Sorry for not being clear and typing garbage. I wrote that mail
before I had coffee...

>
> user1 := RegistryUser new.  (you never defined RegistryUser>>reg; if you
> meant "registry", this would return a Registry)
> user2 := RegistryUser new.
> user3 := user1 copy.
>
> user1 = user2.
> user2 = user3.
> user1 = user3.
> user1 == user3.
> user1 registry = user2 registry.
> user1 registry = user3 registry.
> user1 registry == user3 registry.
>
> If this above is right, I would have expected user1 = user3, but I get false
> (hmm...).  However, user1 registry = user3 registry (which I would have
> expected), and user1 registry == user3 registry, which I did not expect (?)!

The "would have" and "did not expect" are my point.

I'd guess in your Smalltalk

 RegistryUser>>= anObject
   ^ self == anObject

and since user1 and user3 are not the same object (only
referencing the same target), they are considered not =.
And the identity of the registries follows from that.

I remember having a slight epiphany a while ago, when I realised
that "variables" in Smalltalk do *not* contain anything, but
*only* point towards objects piled up in the heap.

With this "finger pointing" in mind, my setup comes down to the
following narrative: user1 references an instance of
RegistryUser containing a reference to an instance of Registry
containing a reference to an instance of Dictionary.
In short:

user1 -> [registryUser#1](
          reg -> [registry#1](
                   dict -> [dictionary#1]
                  )
          )

user2 is basically the same, only with a complete new set of
objects:

user2 -> [registryUser#2](
          reg -> [registry#2](
                   dict -> [dictionary#2]
                  )
          )

Now, copy enters the stage. As shallow copy, it creates a new
instance of its receiver's class, which in turn gets initialized
with the instance variables *references* of the original:

user3 -> [registryUser#3](
          reg -> [registry#1](
                   dict -> [dictionary#1]
                  )
          )

so:     user1 = user3 not,
because [registryUser#1] == [registryUser#3] not.
However since for both users, reg -> [registry#1],
the identity user1 registry == user3 registry is explained.

If you omit "immediate" values (like sufficiently small
integers), objects are just containers for references to other
objects, hence a shallow operation like copy only copies the
structure, not the content.

Time for a small test: Explain to yourself (or to the world at
large), why I suggested "dict keys copy" instead of "dict copy
keys" in your original mail.

HTH,
s.

>
> Rob


--
Stefan Schmiedl
EDV-Beratung Schmiedl, Berghangstr. 5, D-93413 Cham
im Büro: 09971 9966 989, am Handy: 0160 9981 6278

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida