Generation of unique IDs

[Chris Muller]

Fyi, for some reason, your emails seem to be getting sent twice.

> >> 1) Communication between Seaside app and Magma is serialized in such
> >> a way that at any given moment, no two sessions will be performing
> >> the exact same operation? For example, if two users trying to delete
> >> the same object, will seaside serialize each request to Magma so that
> >> the second user will get a transaction commit error because the
> >> object is no longer there?

Well, I apologize too; if you have a lot of MagmaCollections then the notion of
"delete" could apply.  So to answer your original question in that context,
"no", there will be no conflict.

  "in client1"
  mySession commit: [ customerMasterCollection remove: theFredCustomer ].

  "in client2"
  mySession commit: [ customerMasterCollection remove: theFredCustomer ].

customerMasterCollection represents the same MagmaCollection object, whoever
gets to the server last will not have theFredCustomer to delete, but the server
will remain silent about this; no conflict is signaled.  This was chosen due to
the large-nature of MagmaCollections, they need to support high-concurrency.

However, with a Dictionary or any other Smalltalk-original collection, a
conflict (MagmaCommitError) would occur.

> > A more scalable solution would probably be to have multiple seaside
> > servers
> > (separate images), each with their own session opened on the Magma
> > database.
> > Until then, you should consider having one MagmaSession for each
> > seaside
> > session.
> 
> I don't think this is really a practical solution. If you have many
> clients, you end up purchasing alot of hardware and end up with alot
> of idle CPU power. More realistic (for my purposes) is to maximize
> CPU power by sharing it across multiple clients. I think Brent
> Pinkney's suggestion is a more viable and practical solution for my
> needs.

Ok.  The crux of the suggestion here concerns how the program is written;
either sharing a uni-MagmaSession and domain model across all web-clients, or
each web-client having its own MagmaSession.  In the first case, all clients
operate on the same exact domain instances in memory.  In the second, each
client only collaborates on the model through Magma transactions.  Even though
they are in the same memory-space, they can only see changes made to the domain
objects by crossing a transaction boundary (because they each have their own
"copy").

This will allow more hardware to be added more easily later, should it become
necessary.

> I sure did. However, I guess my question was more geared towards the
> interaction of Dictionaries in Squeak in general and Magma's handling
> of it. If you try to update one element of a Dictionary object, will
> the entire Dictionary be "locked" or just the element you are trying
> to update? I understand the principle of optimistic locking. I was
> just not sure as to how Squeak/Magma treated this case.

The logical references from a Dictionary are treated no differently than the
references from any other object.  Consider these examples:

  aCustomer
    name  ("Smith")
    address  (anAddress)

  aDictionary
    anObject -> someValue
    someOtherObject -> someValue

If any of the objects aCustomer points to are updated, then aCustomer is
changed (and "locked").  Now, if the first-class anAddress is updated, but the
customer still points to the same idenntical instance, only the address is
considered changed, not the customer.

In the case of the Dictionary, if any keys are added or removed or replaced
with a different value, the Dictionary is considered changed and subject to the
same concurrency rules as any other object (except MagmaCollections).

Again, MagmaCollections permit add/remove concurrency, even with indexes.

> Would you mind pointing me to more information about UUID?

Look at the class-comment of UUID.  It has a good web-link.

 - Chris