List<ManagedReference> systems = new ArrayList<ManagedReference>();
As i understand one have to create managed references between ones objects instead of “ordinary” ones? But i am not sure I understand why? Does this apply for “static” objects eg stuff that wonr change?
License stuff
Am I allowed to set up my own home server and test and run my game from small servers, or must I make a deal with some certified hosting company?
The first one will mean that the whole list will be serialised in to the database with the object that holds that list, that means that if you get that object, it will also get every single object in the list. If you have these objects as attributes of other objects, SGS will serialise them seperatly, which means you get duplicate objects, and once retrieved, they are no long references to the same instance.
The second one means you just get references, the objects are only got from the database when you call get() on the managed reference.
The things to consider are how often that containing object is retrieved, when you get it, do you need all the child objects?, do you need to get the child objects at any other time?
As for the license, as I read it, you can use it for internal testing, that just means internal to your group of testers as I read it, so using JGO as your testers would be okish I think, and yes, you can run it on your home server. I am not a lawyer though.
We should have the proper open source stack within a couple of weeks though (it’s scheduled for Java One, which is something like the 8th May).
Interesting. I guess I viewed it as UML-style containment versus reference. The first case would be containment and loaded as a part of the containing object. The second case would be lazily loaded as needed (through the get or getUpdate calls on the ManagedReference).
My question is does the data manager take care of returning and synchronizing the duplicate references that might be returned. I had assumed, maybe incorrectly, that if the objects were the same then the data manager would handle the look-ups.
My experience is that the game server doesn’t synchronize the references. e.g. it serializes two copies of the same object. So when you deserialize, I pretty sure you actually get two different object instances. This is almost certainly guaranteed to break things if you trely on referring to the same object in multiple places in your code.
As I see it, the rule is:
If the objects in the List are instance variables (or contained in instance variables) in multiple ManagedObjects, it should be a List of their ManagedReference objects. If the objects in the List are only in that one ManagedObject, then its okay to have a list of the objects themselves.
Sorry. I meant for the second case. I hope the data manager returns the same object, within a transaction, if it were in the list twice. I agree that you get two distinct objects if they are in the list twice in the first case.
Assuming both of these fields are on ManagedObjects then if Sun is a ManagedObject, version1 will fail and throw an exception when it tries to save the ManagedObject that contains the field. this is because storing a direct java reference to a ManagedObject in another ManagedObject’s state is fundamentally incorrect. If it allowed it, you would end up with a COPY of the referenced object, not the referenced object itself.
if Sun *isn’t8 a managed object then there is no way you could save references to it in the lsit in version2 because you can onoly have ManagedReferences to ManagedObjects.
So depending on what Sun is, one of the two is nonsensical and ultimately will not run.
Between ManagedObjects, yes. This is how the system knows its its own object and not part of the state of the ManagedObject containing the reference.
There is no reason to make such a “static object:” a ManagedObject. You will get better performance if you make it a singleton hanging off a static field in its defining class.
But IF you make it a ManagedObject THEN yes you need to use ManagedReferences.
Not being a lawyer i can’t answer that directly. We intend you to download the SDK and use it to develop with. Beyond that, look at the current License] I think its pretty straight forward, really.
When we go Open Source we intend only to expand on the rights your already granted.
[/quote]
Release may get delayed a little. I apologize on that but the team has very strong feelings that they don’t want to dump code on you til its really ready. They’re working hard on getting it to that point now.
