Forum Discussion
M0st1yHarm1ess
3 years agoSeasoned Ace
"ObiDarthYoda;c-2385323" wrote:"StarSon;c-2385291" wrote:"ObiDarthYoda;c-2385283" wrote:"PeachyPeachSWGOH;c-2385235" wrote:
I'm pretty sure nobody would want to rollback the database for this, if we understood the consequences of a database rollback.
Agreed though that the issue does have wider impact and cause more serious damage in TB and Conquest.
Rollback can be for just one 'transaction' - it's not for an entire database.
https://www.techopedia.com/definition/9229/rollback
JUST like banks, etc. do w/ATMs: if the connection is 'cut' in the middle of depositing or withdrawing money, then the transaction is not completed, and nothing is updated in the field(s).
And for EA/CG, who I assume are using mySQL, here ya' go:
The ROLLBACK operation undoes all the changes done by the current transaction i.e. If you invoke this statement, all the modifications are reverted until the last commit or the START TRANSACTION statement.
https://www.tutorialspoint.com/mysql/mysql_rollback.htm
I don't think you really understand what you're saying. You don't even know that it's a database issue, which is honestly unlikely, since it seems to be related to memory usage based on device settings. If it were a database issue it would be much more widespread.
Also, at this point you can't just rollback. It's weeks of play time for hundreds of thousands of players.
I DO know what I'm saying - and if you read my post, it is for ONE 'transaction' at a time - which means ONE battle, etc. Rollback just means the 'transaction' is not 'committed' since there was zero activity. It is NOT for everyone, for all time.
That's not how it works. The beginning of a battle is one transaction, and the end of it is another one. The server does not hold a transaction open waiting for the battle to conclude as all the in-battle events are resolved completely on the client side (which is how cheating based on client side code hacks is possible, by the way).
In general it would be pretty silly for anyone to design a server-side, database transaction to span across multiple client/server round trips. It leaves precious server-side resources to the mercy of varying client access patterns, and, among other serious issues, opens yourself up to DoS attacks.
Back to the issue at hand, in my opinion, the game hangs on entering battle likely after the "start battle' transaction is completed on the server side, for several reasons:
1. If it's the server breaking down in the middle of the "start battle" response, it indeed would have rolled back the transaction automatically. The battle would not have been treated as started. IOW we would not have seen a count of 1 on the client side.
2. If the freeze happens before the client sends the "start battle" request to the server, we would not have seen a count of 1 either, obviously.
3. Only when the client hangs after getting back a successful response from the server, would we be seeing what are seeing now. At the point of entering the battle screen, the transaction has been completed. There is nothing to rollback at the transaction level.
4. If something went wrong on the server side while handling the "start battle" transaction, they would have been able to pinpoint it pretty quickly with all the logging and triaging tools on the server side. The fact that they still haven't been able to fix it makes me believe that it's something happening inconsistently on the client side where they can't see directly.
About SWGOH General Discussion
Discuss and share your feedback on Star Wars: Galaxy of Heroes with fellow players.81,234 PostsLatest Activity: 11 minutes ago
Community Highlights
- CG_Meathead3 months ago
Capital Games Team
- CG_Meathead2 years ago
Capital Games Team
Recent Discussions
- 11 minutes ago
- 47 minutes ago
- 3 hours ago
- 3 hours ago