DataSources are being closed too early and Docs are not clear


So I’ve come across this issue, where the DataSource I get by opening a JDBC-MySQL URL through the SqlProvider gets closed before GameStoppingEvent has been executed.

The docs ( clearly state to not store Connections. But no word about DataSources. And from my perspective that makes sense as creating a DataSource involves at least some kind of parsing the string, etc. So I naturally stored the DataSource I get from the SqlService#getDataSource(jdbcUrl) call.

However this DataSource gets closed before the GameStoppingEvent (not GameStoppedEvent). I mean most plugins using database stuff do at least some kind of cleanup during that stage so I think it’s too early to do it before the event. (After should be fine).

Though if it is intended and the call to get the DataSource is also very inexpensive, it should be also mentioned on the docs.
In any case the example should be extended to show that you either can keep the DataSource or that you can’t.

Now it also mentions that

JDBC URLs should be obtained from SqlService#getConnectionUrlFromAlias(String)

but no example is provided and I honestly don’t have the slightest clue what I should do with that method.
Pass my entire URL to it?
Pass mysql to it?
An example on how to use that would be more than apprechiated.

Now to make this clear, this not a complaint or anything, rather me asking for clarification as I’ve recieved contraticory infomation and some information just seems to contradict common sense/experience.


with an alias that matches one of the JDBC URL aliases listed in Sponge’s global configuration ( config/sponge/global.conf ) under the sponge.sql.aliases key.


I’ve read that, yet still don’t know what exactly I am supposed to do witht that method.

Also do you have any idea about the other points and questions in my post?


I’m really not trying to be impatient here, but some kind of authorative answer would be apprechiated.

If not I’ll have to escalte this into an issue.



So first to answer the whole SqlService#getConnectionUrlFromAlias

Looking through the code of SqlServiceImpl, it appears that when you pass in an alias, it tries to return the String value (I would assume the JDBC String), from the Sponge config:

    public Optional<String> getConnectionUrlFromAlias(String alias) {
        return Optional.ofNullable(SpongeImpl.getGlobalConfig().getConfig().getSql().getAliases().get(alias));

It looks like what you would do is have an alias->jbc string set in the SQL part of the sponge config, and then you could retrieve that String by calling getConnectionUrlFromAlias(<ALIAS_IN_CONFIG>)
I have not used this before, however, if more info beyond this is needed, I could figure it out.

In response to the DataSource issue, here is a bit how the whole DataSource system works (afaik):

  • When you call getDataSource, it does parse the string using regex, which given how often you should be calling this method (not ever single tick… if you’re doing that you are doing it wrong), isn’t that expensive.
  • It then uses that parsed data to create and CACHE a new DataSource. To me that makes it look like you are supposed to call getDataSource every time/frequently.

You also should be listening for the GameStoppingServerEvent, not the GameStoppingEvent.

All GameStop*Events (that arent for the server aspect) may not be executed.

Have you tried seeing if the DataSource is still available in the GameStoppingServerEvent?


Feel free to poke me on Discord if you need help: Snowie (D4rk)#1374

-edit- It is way to early for me to be awake… This could be totally wrong, but I am like 98% sure its right. I apologize for any mistakes :stuck_out_tongue:


Thanks. That helps a lot.

I’ll try to use the GameStoppingServerEvent instead of GameStoppingEvent.
And in my current implementation I call getDataSource every time I create a connection. Though if it’s cached, that should be alright. Though I’d definately prefer keeping the source in a variable for simplicity reasons.

Anyways will be testing some stuff now.