Hi everbody,
before I start, my background: I'm developing webgames which means games that are played via a webbrowser and have MMOG-character in respect to the number of players. Currenty I'm working on such a game which is about to be completed in a few months. With the end of the project in sight I'm slowly starting to lay out the technical possibilities for the next title.
The current game is realized based on MySQL and Hibernate and although the game's concept only aims at 1200 players per physical server, we're already in major trouble concerning persistance performance. The data volume "per player" is quite high and the data is extremely volatile. I figured that realtional databases are probably not the solution of choice for this kind of problem. So when I came across db4o I was immediately fascinated y the idea to use an OODBS instead of the clumsy construct we have in service so far.
Although I think db4o would solve quite a bit of problems for us I still have some worries concerning the quite different structure of my upcoming project. This time, everything will take place on one logical server. One world for all players. To give some figures: I'm targeting about 10 to 50 _thousand_ players for one world. Since it is a game, many players will be online at the same time and the object graph will most likely be as complex as the one in the game I'm working on right now.
My question: If you'd be faced by this scenario, which transaction strategy would you choose? Currenty I keep all writing operations in a simple synchronized block. This is not very elegant but more or less works quite well with our limited player number per server. Obviously with a far higher amount of players and objects this strategy will never work. At the same time, the required programming effort should stay managable. I'm kind of afraid that very complex locking procedures will to some extend destroy db4o's major benefit of a very simple and clean coding structure.
I would be thankful for any thoughts and/or ideas.