Generation of unique IDs

[Daniel Salama]

Sorry for the delayed response.

On Aug 24, 2005, at 2:45 PM, Chris Muller wrote:

>
>
>> 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?
>>
>
> I'm confused by this question.  There is no "delete" of an object.   
> Delete
> occurs in relational databases to remove a row, but with object- 
> databases you
> merely update pointers to new objects.  Perhaps you mean changing  
> the pointer
> from some non-nil to the nil object?

Yes. Please accept my apologies. I come from the RDBMS world.

>
> Magma tries to control access to the server-link from multiple  
> processes
> accessing the same session.  I'm not completely clear about the  
> design you are
> describing though, so hard to say..
>
> If using a single Magma user, it will probably not scale well.   
> Magma was
> designed to support a lot of users; most of the burden is on the  
> client.  By
> converging all user db requests through a single Magma session in a  
> single
> image, it will severely limit performance.

Advise accepted

>
> A more scalable solution would probably be to have multiple seaside  
> servers
> (separate images), each with their own session opened on the Magma  
> database.
> Until then, you should consider having one MagmaSession for each  
> seaside
> session.

I don't think this is really a practical solution. If you have many  
clients, you end up purchasing alot of hardware and end up with alot  
of idle CPU power. More realistic (for my purposes) is to maximize  
CPU power by sharing it across multiple clients. I think Brent  
Pinkney's suggestion is a more viable and practical solution for my  
needs.

>
>
>> 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.
>>
>
> Yes, transactioons are atomic.
>
>
>> 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?
>>
>
> If two sessions update the same object without having the latest  
> view of it,
> the second session will get a MagmaCommitError signaled.
>
>
>> 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"?
>>
>
> Magma uses optimistic locking.  I assume you read the Magma pages  
> about this..

I sure did. However, I guess my question was more geared towards the  
interaction of Dictionaries in Squeak in general and Magma's handling  
of it. If you try to update one element of a Dictionary object, will  
the entire Dictionary be "locked" or just the element you are trying  
to update? I understand the principle of optimistic locking. I was  
just not sure as to how Squeak/Magma treated this case.

>
>
>> 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?
>>
>
> Yes.
>
>
>> Thanks for your input.
>>
>
> I don't fully understand your implementation using a Dictionary to  
> calculate
> the next customerId but..  Generally, if you have a single object  
> keeping track
> of an id then, as you see, there will be a lot of concurrency on  
> that object.
>
> It might be better to generate id's (take a look at UUID, I believe  
> it can be
> customized if you don't like the id's it generates).  Another  
> option (and I
> shudder to say this) you could use oids for your id's.

Would you mind pointing me to more information about UUID?

>
> I'm sure I don't fully the nuances of your question..
>
>  - Chris
>

Thanks for your comments. Look forward to hearing back from you.

Thanks,
Daniel