[Question]: Will database operations be handled asynchronously?

[rugiaDev]

Your Question

Hi, thanks for your great work on LiteEco.

I have a question regarding database operations.
Currently, player data (such as balance) is saved and loaded synchronously, including on player quit.

This raises a potential issue when switching servers through a proxy setup (e.g., Paper/Velocity).

• Example: A player quits Server A → data is still being saved → at the same time, the player joins Server B → Server B loads old data before Server A finished saving.
• In this case, there is a risk of duplicated or inconsistent balances (e.g., money duplication).

My question:
Do you have plans to handle database save/load asynchronously, or to add safeguards (e.g., locking, queueing, Redis presence keys, etc.) to prevent this type of issue?

Thanks in advance!

[EncryptSL]

Database operations are asynchronous, LiteEco uses coroutines, and coroutines are asynchronous.

I understand what you mean, when using a proxy server there is a small risk of duplication...
However, I currently have no reports of duplication with the proxy server...

I'll try to come up with something to minimize this risk.

[Navio1430]

(I'm writing this without checking the code thoroughly first)

There shouldn’t be a problem if the DB is used as the main source of truth.

• It will work as long as changes are committed directly to the DB instead of being cached and pushed later (e.g., scheduler, leave event). You can use the Write-Through caching pattern/strategy (if you don't do that already).

[Navio1430]

Okay I forgot it's local cache, not Redis. The best way to maintain ACID here would be making the DB main source of truth in both read/write ig