Generation of unique IDs

[Daniel Salama]

That would be a great thing to have. That way I could potentially  
manage multiple MagmaCounters per application to handle multiple  
counter needs.

Thanks,
Daniel

On Aug 25, 2005, at 2:35 PM, Chris Muller wrote:

> 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
>>
>>
>>
>
>