Generation of unique IDs

[Chris Muller]

> I'm using Seaside with Magma. I guess that I could design the app in
> Seaside so that there is a single user (e.g. seaside) logging into
> Magma for a particular application. I also assume that regardless of
> the number of users hitting the Seaside app, there is a single
> instance of the app managing multiple sessions. Is it safe to assume
> the following:
>
> 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?

I'm confused by this question.  There is no "delete" of an object.  Delete
occurs in relational databases to remove a row, but with object-databases you
merely update pointers to new objects.  Perhaps you mean changing the pointer
from some non-nil to the nil object?

Magma tries to control access to the server-link from multiple processes
accessing the same session.  I'm not completely clear about the design you are
describing though, so hard to say..

If using a single Magma user, it will probably not scale well.  Magma was
designed to support a lot of users; most of the burden is on the client.  By
converging all user db requests through a single Magma session in a single
image, it will severely limit performance.

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.

> 2) I maintain a dictionary of IDs in Magma so that when a new
> customer is created, the app looks up the next customer ID in the
> dictionary, and increments the count. I would assume that if I put
> this code along with the code to create the customer object in the
> same transaction, it should all happen atomically.

Yes, transactioons are atomic.

> My question is
> (and somehow related to the above question) if two users are creating
> different customers, what inherent fail safe mechanism exist so that
> the second transaction will get the updated next customer ID from the
> dictionary during its transaction process?

If two sessions update the same object without having the latest view of it,
the second session will get a MagmaCommitError signaled.

> 3) I believe the way squeak works with Dictionaries is that it tries
> to load it all in memory. Will it do the same with a Magma loaded
> Dictionary? The question is more geared to answer the following
> question: if I am in a transaction creating a new customer and I have
> the Dictionary element of customer IDs "locked", will the entire
> Dictionary be "locked"? 

Magma uses optimistic locking.  I assume you read the Magma pages about this..

> If another transaction is occurring at the
> same moment where another user is creating a sales order and the app
> tries to get the next sales order number from the same dictionary,
> will it find a conflict?

Yes.

> Thanks for your input.

I don't fully understand your implementation using a Dictionary to calculate
the next customerId but..  Generally, if you have a single object keeping track
of an id then, as you see, there will be a lot of concurrency on that object.

It might be better to generate id's (take a look at UUID, I believe it can be
customized if you don't like the id's it generates).  Another option (and I
shudder to say this) you could use oids for your id's.

I'm sure I don't fully the nuances of your question..

 - Chris