Possible to delay a PlayerQuitEvent until some task is finished?

Discussion in 'Spigot Plugin Development' started by JacobCrofts, Jul 2, 2016.

  1. I am using BungeeCord, but I don't think this is a BungeeCord-specific question nor are my plugins BungeeCord plugins so I'll ask my question here.

    When a player hops from one server to another, the player's inventory contents must persist. I handle this by saving a player's inventory to a web database upon PlayerQuitEvent, and loading the player's inventory contents from the database upon PlayerJoinEvent.

    I was getting some unexpected behavior on the part of my web app:

    Despite PlayerQuitEvent firing before PlayerJoinEvent when a player transfers servers, my PATCH request to the web app fires after the GET request (as indicated on the web console). In other words, the inventory reloads on the new server before it saves its old contents to the database.

    I resolved the issue by delaying the inventory reload task upon PlayerJoinEvent. This is not an ideal solution, because the amount of time it takes to complete the PATCH request is variable. Additionally, logging in and waiting a few seconds to get your items is a bad user experience.

    Does anyone have a better solution?
     
  2. Instead of saving items on PlayerQuitEvent you could instead save each change on any kind of InventoryEvent. That way it would always be up to date.
     
  3. FormallyMyles

    Supporter

    You should be able to just retain the Player instance, but don't hold on to it longer than you should as that would cause memory leaks.
     
  4. Why are you using a webserver in the first place, instead of a database?

    Regardless, you could force the player through an intermediate lobby, and only let them join a new server once the last server is done with saving (and f.e. sets a server_lock field in their data to NULL), which allows them to join a new server.
    That doesn't avoid race conditions though (which is what OP is having issues with)
    How would this solve OPs syncing issue though :p. There's no need to hold the Player instance manually since the scope would do this for you (assuming saving is done in the PlayerQuitEvent, or a Runnable which is produced in the PlayerQuitEvent)
     
  5. In the long run, I hope to have a fully web-integrated economy, and most administrative functions will be hosted on my web app. When I first began my project, I made a post about how I should approach data management given my goals (would fetch it but my toast just popped). The general consensus was that a web database is the way to go.
     
  6. Web database != web server :p. All applications (MC server, web app) should query and modify the database directly.

    (I also poked the other thread, hoping to get a reply from the people who originally suggested it - since I still consider them good developers, so perhaps there's a reason for it which I don't know about)
     
    #6 DarkSeraphim, Jul 2, 2016
    Last edited: Jul 2, 2016