SGS database consistency model?

Networking & Multiplayer
#1

Is the consistency model for the SGS globally sequenced?

Thus, if I peek object A on node X, then lock/write object A on node Y, then lock/write object A on node Z (which clearly sees the state from node Y), then attempt to peek object A on node X again, am I guaranteed to get the state as written from node Y or later, or is there a chance I could get the earlier state I already peeked?

I e, is the consistency semantic that a commit will always distribute state, even to peek/readers, or will the local node really only know that the view of state will advance when it actually locks/writes? The latter has performance benefits, but implementation pains…

#2

Its a bit simpler to explain, actually. These are the guarantees:

(1) Peeks are repetable within a task. After the first peek subsequent peeks willr eturn the same object EXCEPT
(2) Doing a GET effectively resets the state so after a GET all subsequent peeks will return the same obejct as the GET. If you are keepign referecnes to the result os previous peeks though those remain the original object.

#3

Thanks for the explanation. That doesn’t, however, talk about the consistency model between different tasks.

Does a commit mean that any PEEK done physically after the commit completes will see the committed state, or can a physically later PEEK actually return data that is part of the pre-commit state? My guess is that, yes, a PEEK can actually return state that is out of date WRT the commit state of the object, and you’ll have to use GET if you want to ensure you have the “latest” state.

I’m assuming that successive GETs are synchronized and serial (and, in fact, you can’t GET an object at two places at physically the same time).

#4

If I’m following your question hplus and understanding the SGS model correctly, then your answer should be that after the commit any PEEK will return the new object. Even though the game servers are running on multiple seperate nodes, they are all drawing from the same central data repository ( if part of the same “game world” ). It is not that the information is being sync’d across multiple game server nodes and there may be a lag. They all go to the same source.

Hope that helps ( and hope that was correct! ;D )

#5

The way I understand Jeff,
If process A peeks GLO “blahblah” and sees the value “one”
Then process B gets GLO “blahblah”, also sees value “one”
process B then commits a new value “two” to GLO “blahblah”

now AFTER this commit, if process A does another PEEK at “blahblah”, it will still see the old value “one”, because inside one process, all PEEK’s return the same value.

quote Peeks are repetable within a task. After the first peek subsequent peeks willr eturn the same object EXCEPT
[/quote]
B, on the other hand, will read the new value “two”, regardless of PEEKing or GETting.

#6

Hi

As I understand Jeffs other posts elsewhere, after process B does it’s get, nothing in any process can do a peek until the commit has happened, and at that point, it will get a different object because the commit has happened. It only returns the same GLO object if it’s data is unchanged.

Endolf

#7

Okay guys… let me try to explain this clearly. Im sorry its so confusing… but anyalternate models we coudl come up with that didnt have really vicious over-head were even more confusing…

There is always a value in the object store to be PEEked. It is the last comitted value of the object.

This does not change until a transaction that has done a GET on the object, and subsequently modified it, commits.
At that point there is a new value to be PEEKed in the object store.

Now inside of a single transaction, what happens on GET and PEEk is kind of important to completing the story so heres how it works:

When you PEEK the first time, you get a refernce to an object that is a copy of that state in the object store.
Subsequent PEEKs will return a reference to that same object. Even if another transaction comes ina nd commits a new value,
you won’t see it because you arelady have a peek-copy locally.

The one time this chnages is when you do a GET. When you do a GET the first time, a new object representing a copy of the current state in the object store is made at the same time the GET-lock is taken.
After this, any subsequent GETs return a reference to that copy.
ALSO after that GET any subsequent PEEKs return a reference to the copy returned by GET… even if you did a PEEK before the GET.

That last line is the sort-of-tricky part. But it really does result in the code doing “what yo uwant” in an intuitive manner the vast majority of times.

#8

Cool, that clears up in instance things, but what about across instance of SGS on ‘the big backend’. If I peek from a task, and on another instance else where in the cluster, another task does a get, what happens if I peek again from the original task?. I can’t get a reference to an object that is on another machine unless you are using RMI or something along that lines, so do I get the same instance again?. What happens across instance of SGS after the commit?

I know this is a complicated area, otherwise we would all have written code to do it ourselves :slight_smile:

Just trying to get it straight it my mind.

Endolf

#9

THink of the ObjectStore as a “vault” or cold-storage. Object in the obejct store are just images. They dont existas objects untuil pulled into a GLE.

In the case of a PEEK, a transaction-local copy of the object is created from the value in the GLE for use.
If another transaction does a PEEK it creates it own transaction-local copy.

In the case of a GET, the same thing happens but additionally a flag is set on the cold-storage to make any other attempts to GET on it block until
the currently lock-holding transaction is complete.

It doesnt mater where the transactions live… one machine or many. Each gets its own copy.

Does that make more sense?

#10

Chat log with Jeff cause I still didn’t get it fully :slight_smile:

HTH

Endolf

#11

So the consistency is on a per-task basis – specifically, a SGS execution process cannot locally cache the value of a peek between tasks, because the consistency model says that any new task (after a possibly remote commit) must return the committed value. This is nice for the object programmer, but a draw-back for someone attempting to implement a high-performance object store.

With the model, as described, then either each node cannot have caching (slow), or each node needs to participate in a global two-phase commit procedure (quite complicated).

If the rule was changed so that a task may get an older version of data unless it does a GET, then the implementation could be allowed to cache, and use a non-synchronous cache flush protocol, which would be higher performance and more robust (on the implementation side). The draw-back would be that you could get an older peek value after a newer commit – but, really, if you’re running on a different node, synchronization isn’t guaranteed anyway.

#12

Yup. The goal is to make it easy and simple for the programmer. We are doing everything we can to avoid compromising that.

Thats why this is a labs project, we are solving really hard problems.

Actually there are other solutions having to do with aggregtaing and migrating users around the back end according to usage patterns.

Yes, it IS rocket science. Thats why I have rocket scientists on the project. 8)

#13

[quote]Actually there are other solutions having to do with aggregtaing and migrating users around the back end according to usage patterns.
[/quote]
You can distribute ownership, but ownership needs to be in one place at a time. Thus, ownership can migrate to the “most likely” node to want to next GET the object.

However, distributed ownership still needs the (moral equivalent of) a transaction monitor to arbitrate ownership. No two ways about it – anything less and you have a chance of ownership schizophrenia. And you really don’t want that! (Speaking as someone who solved this problem five years ago)

#14

There are other solutions, and hybrid solutions.

Objects are not the only mobile thing in the system.

I really cannot say more because the guys in research are still finalizing details and we havent even begun to work through the patent process yet. When we have it all up and running in the big back end and the right patent apps in place I am sure we’ll give some talks and publish a paper or two.

But dont fall into the trap of thinking that because you find a soluition it is the only solution. Thats pretty much never true in computer science.

#15

[quote=“Jeff,post:12,topic:27624”]
Yeah but, rocket scientists don’t necessarily make good programmers. :slight_smile:

(I know of a NASA group that had a poor understanding of modern computers and computer science. It was clear that their skills in the CS area were lacking when my development team had to bail them out.)

But I must admit what you guys are doing with the SGS is exciting and I’m sure you’ve got some smart guys on the team or you wouldn’t be as far along as you are. I only wish that I had the time to start a project that used the SGS so I could get in on the excitement.