On Fri, 2008-03-21 at 15:10 +1300, Lee Begg wrote:
> Hi all.
>
> I feel I need to push a new release out to get rfts released before the next
> gsoc starts, and there are a *lot* of changes since the last version.
It's good to see that you are thinking about a release. There have been
massive changes since 0.4.1 and I would really love to see a new
version.
> There a some substantial changes I would like to make soon and quickly,
> namely
> making the Manager's asynchronous to improve the performance of the server.
To be honest I would wait until after a release for these changes. We
have not hit any type of performance problems with tpserver-cpp yet
(specially the networking side).
> Persistence in tpserver-cpp is quite well broken and all the current work I'm
> doing to fix it will have to be done again anyway.
My theory is something like this, "A crash which looses data is critical
while a crash which doesn't loose data it is only an annoyance".
Following this theory persistence is very important as any segfault at
the moment causes you to loose the complete game you are playing. (In
theory) With working persistence you could just restart the server and
continue playing.
I did investigate other ways to provide this functionality (such as
restartable core dumps or dumping the internal memory database) but they
all would require more work then just fixing persistence.
> I am proposing to remove the mysql module from the build and the tarball. It
> will be left in it's current condition in git. Is this acceptable? Comments?
Would doing a sqlite or other module be quicker? My guess is updating
the mysql one is going to be our best option.
I would recommend getting it into a state where the database is always
in a consistent state before and after turn processing. Being able to
restore to the last "good" state would be very useful (IE just after the
last turn processing occurred). This could be done by wrapping
everything else in a huge transaction (make sure you are using InnoDB).
If you loose a few orders here and there it is not such a huge problem.
So my proposal looks like this
- Turn Generation Ends
>> Begin "User Data" Transaction
- User submit orders
--> If a segfault occurs here, the database is left in a
pristine "turn finished state"
- Turn Generation Is About to Start
>> Commit "User Data" Transaction
>> Begin "Turn Processing" Transaction
- Turn Generation is performed
--> If a segfault occurs here, the database is left in a
pristine "all user orders submitted state"
>> Commit "Turn Processing" Transaction
That diagram looks pretty confusing, but it should be fairly simple.
Tim 'Mithro' Ansell
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
