Your opinion on database access for economy plugins

Discussion in 'Spigot Plugin Development' started by ZeroxTV, May 16, 2019 at 3:40 PM.

  1. Hey everyone,

    so what I'm asking for is basically just your opinion on this question:

    Should an economy plugin do every transaction directly on the database, or work with a local copy in java that is loaded from the database and saved with the world?

    My opinion:
    Work with a local copy and save all data to the database whenever the world is saved, because otherwise there is the possibility of duplications or value loss, when the server crashes without saving.
    When you buy something from a shop, place it down and the server crashes, you lost both the money you paid and the block you should have received for the payment.

    On the other hand, if a player spends time to grind some currency and it is reset due to a server crash, that's also really annoying.

    So what do you think?
     
    • Agree Agree x 1
  2. Directly in the database is the better. Also, remember doing it async.
     
  3. Personally I only load data for the players that are online, and save it every 30mins/when the player leaves
     
  4. Directly on a database.

    (I think you should use relational databases to avoid duplicates, but I am not sure)
     
  5. So you don't think that value duplication or loss would be a big problem?

    Well, after all, I guess when the server does a hard shutdown, without saving the world and everything, a few missing bucks on some accounts would be my smallest problem.
     
  6. Thanks for the tip, I would have probably forgotten
     
  7. Yes and no, but there isn't enough time to save everything. That's why you should save data every 30 min.
     
  8. You are confusing me, so do you think I should do transactions directly on the database, so basically save instantly on every interaction, or should I save every 30 minutes?
     
  9. oh whoops.
    Everytime a transaction occurs, you should instantly save it in the database.
     
  10. If you're talking about Vault economy, take into account that other plugins may not call methods async.
     
  11. Nope, not talking about vault. Making a bunch of custom plugins right now, and the core plugin also includes a economy module.
     
  12. Well, if you do things correctly, your server should never crash. So saving a caching the eco profiles for 10 minutes or so and then saving them to the database should not be too bad.
     
  13. I think directly with the database works best as long as you do it asynchronously
     
  14. Well yes, but even the best server administrator can't prevent a sudden power outage.

    Also, so you think I should keep a local copy of the eco data and save it every few minutes, right?



    Many of you said that I should do it directly on the database, but you don't give any reasons. What do you think are the benefits of directly working with the database instead of a local copy?
     
    • Agree Agree x 1
  15. In the event that the server crashes because of a power outage or anything else, it’s nice to have their data saved each time it changes rather than have it save every so often because if the server crashes between save intervals, it will erase all the new data that was cached and ready to be stored. It’s also nice to have the saves spread out rather than all at once because that’s nicer on the thread (although it shouldn’t lag the server if it’s being done asynchronously).
     
  16. What I'm thinking about is that the world itself isn't saved on every interaction. So why should the economy system be? This way, the possibility arises of the two not being in sync anymore. The economy data is fully up-to-date, but the world save is still from half an hour ago because the server crashed before it could save. That's the main thing I'm worried about.

    I just still don't see the benfits of directly working with the database.

    In case of a multi-server-network: Yes, absolutely! The servers need to be in sync regarding the data they use, but for a single server instance I don't see the benefits.
     
  17. Strahan

    Benefactor

    Well, world data =/= economy data. Just because you lose x minutes of one doesn't mean you need to pointlessly throw away x minutes of the other. Less to recover then.

    Really depends on how busy the server is and whether or not the owner is a cheapskate. For a good server running on quality hardware, MySQL will be fast and responsive and the load would not be an issue. MySQL is used in environments with way more load than an MC server. Personally, I'd rather have instant updates for the sake of integrity. Maybe if I had a server with some hundreds of thousands of users all transacting business at once it may be better to cache, but that'd never happen anyway.
     
  18. But if you don't throw away x minutes of the other, than the two things arent in sync anymore, and when you rollback to the last time it was saved then value has been duplicated or lost, because the baught items are gone, and the money you paid too, or the item you sold is back in your inventory, but you still have the profits of selling it.

    Btw, I like MongoDB more and that's why I'm using that and not MySQL ;)
     
  19. I agree with you especially for with inter-player transactions.
     
  20. Sorry, but can you explain a little bit more why you want to have a local copy instead of writing directly? And what you mean by local copy (specifically where/what is this local copy)?

    If I understand this right:

    I don't see a difference between having a copy and writing directly. So I'm going to assume when you say "local database" you mean on your host computer, as files. I assume this because saving it in the JVM's Heap Memory poses the same amount of problems, if not more, in the "server crash scenario"

    This is because if your local database is stored in memory in the instance of your plugin, when the server crashes the plugin will crash with it. Since all of your data lives in the plugin instance, all of your data is lost, and you won't be able to get those last little bits of data to save.

    Having a local copy of the database will use up more resources due to more data writes.

    On startup you retrieve a copy of the database and store in it memory (depending on how big your database is this can be a problem, a 100 entries won't do much, but imagine having a million objects stored in memory). If you really want to make a local copy, make a local copy only of the data needed, not the entire database and update it is as need need be.

    And after that, writing to your local copy which writes to the database ends up doing the same thing as writing directly to the database, you essentially have a database for your database which doesn't really make sense.

    The local database becomes a middle man that doesn't need to be there. It's like passing a note to your friend who passes it to another friend when you can just pass the note to the other friend directly.

    So you end up writing the same data twice instead of just once.
     

Share This Page