I really cant understand what you are up for. Are those 2 work stations part of the same server-cluster (or THE server-cluster) or are you talking of separate systems running separate instances of SGS on each of them?

In the first case there is ofcourse no connection between both game, because it would be like I am running a game with SGS on my computer here and you are running a game on your computer there - so why should they talk to each other by itself?

In the second case if both work stations are part of the same server-cluster just 1 SGS is running on them and there is 1 ObjectStore per game. So if you install the shooting game once on the SGS all players logged in to any computer on the cluster will use the same ObjectStore. But if you install the same game twice or several times on the same SGS with different game IDs every instance of the game on the SGS will get its own ObjectStore and there is no internal communication between those games even all are using all servers in the cluster concurrently.

You could establish a communication gateway from game to game using a special "client" which logs in to all the games and transfers data from one game to the other - but that would be a very unsafe and limited way of communication; to say it more clearly, it would be a hack.

Maybe tell us about the idea behind your wish to do that in this way .... maybe we can find some better solution for it.

In a full SGS abck end there are many physical computers-- we will call them "boxes" fir the purpose of this discussion.

Each box runs what we call a "slice". Each slice has a communications tier, a game logic engine, and interfaces to object stores. It does not contain the Object Stores themselves, they are external and adressed by many slices at once. Each slice can have N games installed in it. Each game references its own object store and has iots own channel name-space.

The same game, installed into muiltiple slices, all reference the same object store and channels. They are a;; efectively "one application" running across many boxes. This is how we scale and fail-over in the case of individual box failures.

Now the SGS server you get as part of the SDK does NOT do this. It has the entire object store in it, not just an interface. This is pusposeful. The SDK server does NOT scale, does NOT fail-over and is NOT intended for production use.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

Each box runs what we call a "slice". Each slice has a communications tier, a game logic engine, and interfaces to object stores. It does not contain the Object Stores themselves, they are external and adressed by many slices at once. Each slice can have N games installed in it. Each game references its own object store and has iots own channel name-space.

The same game, installed into muiltiple slices, all reference the same object store and channels. They are a;; efectively "one application" running across many boxes. This is how we scale and fail-over in the case of individual box failures.

This kind of confuses me. What is the term "installed" here?- I thought of it like that installing a game means the XML deployment descriptor is assigned to each box while the boot GLO (which might install the game world if needed) is just called once during the cluster is booting, not for each and every box. Clients would know of those boxes from the discovery.xml and can login to one of them. So what exactly is the term "installed in a slice" here?

Jeff, might it be possible to get direct access to the underlying database of the SGS maybe via a method in the SimTask object much in the way like a socket is opened from there yet, but the message would be an SQL request to it. The reason I ask here is that the underlying database is maybe highly accessible (you said HADB, I looked at it and it seems to be a really safe technology) and data you want to store outside the GLO pool (i.e. the ObjectStore) would be able to make use of these super-safe storage and SQL queries.

Breaking down the game logic and data into GLOs is ok as far as this data is small enough per GLO (because it is loaded and stored in full), but it becomes a pain and a bottleneck if you need to access mass data this way and want to get meaningful information out of it. What is easy using SQL on a real database becomes a pain when it needs to be performed on GLOs - and because of the short-lived nature of a task I dont believe in any sophisticated information to get out of hundreds or thousands of GLOs. Breaking this down into task and child-tasks does not help here because using another task means there is no longer transactional safety for the whole query operation.

I hope I have explained it good enough to show the need of external database access and why we want to use the (maybe highly accessible) database system in the SGS.

In a full SGS abck end there are many physical computers-- we will call them "boxes" fir the purpose of this discussion.

Each box runs what we call a "slice". Each slice has a communications tier, a game logic engine, and interfaces to object stores. It does not contain the Object Stores themselves, they are external and adressed by many slices at once. Each slice can have N games installed in it. Each game references its own object store and has iots own channel name-space.

The same game, installed into muiltiple slices, all reference the same object store and channels. They are a;; efectively "one application" running across many boxes. This is how we scale and fail-over in the case of individual box failures.

Now the SGS server you get as part of the SDK does NOT do this. It has the entire object store in it, not just an interface. This is pusposeful. The SDK server does NOT scale, does NOT fail-over and is NOT intended for production use.

Jeff:is it becos the SDK server is limited to 1 slice tt's why it does not scale?as the SDK server does NOT scale, will the SGS SDK works for server clusters?

It will, because all those APIs in the SDK never have anything to do with the process of farming out GLOs on a server-cluster. The server-cluster itself is transparent to your development as well as the underlying database for the ObjectStore.

I thought of it like that installing a game means the XML deployment descriptor is assigned to each box while the boot GLO (which might install the game world if needed) is just called once during the cluster is booting, not for each and every box.

No. A slice is the stack of softare that runs on a box. The boot GLO is called for each slice. This is necessary to register your callbacks on that slice (trust me,)

FIrstTime however is only true ONCE across all boots of all slices as long as the obejct store is not cleared.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

I hope I have explained it good enough to show the need of external database access and why we want to use the (maybe highly accessible) database system in the SGS.

Its an interesting thought. Unfrotunately exposing the database would make the ObjectStore interface in the system SQL specific. Currntly it is not and I dont really want to put that limit on an implementation.

How to do RDBMS stuff though in general is an interesting question. Let me ponder it a bit...

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

Its an interesting thought. Unfrotunately exposing the database would make the ObjectStore interface in the system SQL specific. Currntly it is not and I dont really want to put that limit on an implementation.

How to do RDBMS stuff though in general is an interesting question. Let me ponder it a bit...

We would not want to access the ObjectStore by SQL (the ObjectStore keeps being untouched as before), it would just be adding another option to use the underlying (highly accessible?) database as RDBMS. And because SQL is most common I thought of an SQL interface in addition to the already existing methods in the SimTask object - so from my perspective this is not a limitation but a new option, which would make more efficient use of the maybe expensive hardware (=HADB + dedicated database servers). HADB has no other use than serving as a highly accessible database system ... but SGS is just using it like a very expensive hashtable.

Hm, yes, it is true, that is a nice feature too. But I would not say that those missing relational database features, query and manipulation abilities would just count as 50% of the database features. If you are used to express and query your data in relational tables you will heavily miss those if they are no longer there.

Ofcourse some of those features could be intergrated using an external database from inside the SGS via the SimTask.openSocket(....) method and the associated callbacks via a GLO, but it would call this GLO 3 times for a single query, while an implementation via a new SimTask.startSQLQuery(....) method could do this by just invoking the callback GLO once (maybe with an automatic deletion of this GLO when this callback task ends). Wouldnt that be a much more efficient way to use relational database features from inside the SGS?

That link is also that info I read about the HADB technology - it is a highly accessible database capable to repair itself when an error occurs. Jeff said, HADB is planned as backend storage in the "big" version of a SGS installation, afaik.

HADB is indeed a technolgoy we are looking at striongly for objectstore implmementation.We have some large scale scalign concerns that may result in our adding to the HADB model to support. This is all in heavy research right now.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org