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
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:
- 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?
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.
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 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.
- 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..
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.
I'm sure I don't fully the nuances of your question..
- Chris
Until then, you should consider having one MagmaSession for each seaside session.
That is precicely what we have implemented - it works beautifully.
Allocating a new MagmaSesison is quite slow as it must perofrm a lot of consistency checks on the image to confirm it is compatible with the objects in the repository. This can make the Seaside app look sluggish as allocating new Seaside session is a pretty frequent occurence.
A nice optmisation is to always have a MagamSession pre-allocated which can be used by a new Seaside session. Another MagmaSession can then be allocated asynchronously.
Brent
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:
- 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.
- 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.
- 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
Fyi, for some reason, your emails seem to be getting sent twice.
- 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?
Well, I apologize too; if you have a lot of MagmaCollections then the notion of "delete" could apply. So to answer your original question in that context, "no", there will be no conflict.
"in client1" mySession commit: [ customerMasterCollection remove: theFredCustomer ].
"in client2" mySession commit: [ customerMasterCollection remove: theFredCustomer ].
customerMasterCollection represents the same MagmaCollection object, whoever gets to the server last will not have theFredCustomer to delete, but the server will remain silent about this; no conflict is signaled. This was chosen due to the large-nature of MagmaCollections, they need to support high-concurrency.
However, with a Dictionary or any other Smalltalk-original collection, a conflict (MagmaCommitError) would occur.
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.
Ok. The crux of the suggestion here concerns how the program is written; either sharing a uni-MagmaSession and domain model across all web-clients, or each web-client having its own MagmaSession. In the first case, all clients operate on the same exact domain instances in memory. In the second, each client only collaborates on the model through Magma transactions. Even though they are in the same memory-space, they can only see changes made to the domain objects by crossing a transaction boundary (because they each have their own "copy").
This will allow more hardware to be added more easily later, should it become necessary.
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.
The logical references from a Dictionary are treated no differently than the references from any other object. Consider these examples:
aCustomer name ("Smith") address (anAddress)
aDictionary anObject -> someValue someOtherObject -> someValue
If any of the objects aCustomer points to are updated, then aCustomer is changed (and "locked"). Now, if the first-class anAddress is updated, but the customer still points to the same idenntical instance, only the address is considered changed, not the customer.
In the case of the Dictionary, if any keys are added or removed or replaced with a different value, the Dictionary is considered changed and subject to the same concurrency rules as any other object (except MagmaCollections).
Again, MagmaCollections permit add/remove concurrency, even with indexes.
Would you mind pointing me to more information about UUID?
Look at the class-comment of UUID. It has a good web-link.
- Chris
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@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:
- 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
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@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:
- 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
Ok, I'll start thinking about it.
I hope you are weathering Katrina ok!
- Chris
--- Daniel Salama dsalama@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@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:
- 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
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@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@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:
- 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
magma@lists.squeakfoundation.org
-
Brent Pinkney -
Chris Muller -
Chris Muller -
Daniel Salama