Entity management question with sim-eth-es

I am building off of sim-eth-es … all is fine except for one question…

All the entities get loaded up in the server’s EntityData instance … thousands of them … now the problem is that each user also can have thousands of entities (researched parts, hull parts, etc…). What’s the best practice to manage the user’s entities separately? My thought is to have a separate EntityData instance for a logged in user under their session and then garbage collect it when they log off but I can’t find such a mechanism in the sim-eth-es code base.

I’m trying to understand why you would need this. Where are that users entities when they are not logged in?

I am worried about loading every possible entity into memory including every users inventory item, posible ship in bay, researched item, etc … with 30k users you can imaging it can get large quick. The user’s entities are really not used in shared space and only used by a logged in user so they can build ships they might launch later for example. I figured I would have one shared EntityData for all entities in sector space and only instantiate user entities when a user logs in and garbage collect them when they log out.

EDIT: so basically the user’s entities are private to the user and are not needed as public entities for other’s to get.

EDIT #2: I guess I can have a hollow “ReasearchedItems” component on the user’s entity and then lazy load the stuff from the database on the client’s side via RMI … but then I don’t get the benefits of an entity subsystem for those.

So normally your whole ES is in memory and not backed by storage?

I never had time to look into the DB adapter code. You telling me that the DBAdapter is a lazy loading mechanism that dynamically applies Filters so that I don’t need the world in memory on the server? … Now THAT would be cool!

Yes. Where possible, the filters are translated into queries. Only what is needed in memory is loaded into memory.

So the performance profile will change but likely in ways not important to a networked app that may have already had to deal with those same types of resident issues.

Edit: note that also only components marked as persistent components will be stored and anything else will be memory-only just like you have now. So for things you only use at runtime you still get the same performance.

1 Like

Once again you trumped my needs with your libraries because you have architected them with most fringe cases dealt with. Thank you!

Haha… don’t thank me until it works. :slight_smile:

Seriously, though, I used this for Mythruna as it would have been impossible to keep everything in RAM all the time.

So all I have to do is replace the EntityData on the server with a SQLEntityData? Could it be that simple??

And mark persistent components with the PersistentComponent interface.

As long as they can be saved/loaded by treating their fields primitives or objects with primitives then you should be fine.

1 Like

So all the EntitySets I get on the client are only backed on the server in my client session and garbage collected on disconnect correct?

That’s the way it’s supposed to be.

1 Like

OK is hsqldb part of the JDK now? I don’t see the jar in the zay-es distribution.

EDIT: Never mind. I have to manually add the library :slight_smile:

Yeah… classic JDBC pattern of “put this in the right place and pray”.