Generation of unique IDs

Chris Muller afunkyobject at yahoo.com
Thu Aug 25 18:35:54 UTC 2005


It don't think it would be hard to add a MagmaCounter that would do what you
want.  You could initialize it with a value and then say, #next.  It would be a
server request so it would be sychronized, guaranteeing a unique # with no
commit-conflict..  Interesting.

If this would help you out a lot Daniel, I will try putting it together for
future version..

 - Chris

--- Daniel Salama <dsalama at user.net> wrote:

> 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