Generation of unique IDs
Daniel Salama
dsalama at user.net
Tue Aug 23 23:02:10 UTC 2005
I have a general question on the generation of unique IDs for things
like customer number or invoice number, etc.
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?
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. 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?
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"? 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?
Thanks for your input.
- Daniel
More information about the Magma
mailing list