Generation of unique IDs

[Daniel Salama]

Thanks. Katrina left me with no power since last night 7:30PM. I'm  
working out of a hotspot today :)
  I hope to get power back in my house by tomorrow.

Thanks,
Daniel

On Aug 26, 2005, at 12:53 PM, Chris Muller wrote:

> Ok, I'll start thinking about it.
>
> I hope you are weathering Katrina ok!
>
>  - Chris
>
> --- Daniel Salama <dsalama at user.net> wrote:
>
>
>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>