Generation of unique IDs

[Chris Muller]

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