DatabaseFactory.create() reuses/collides state for explicit Database instances with same name but different DataSources since 19.1.0

[Incanus3]

After upgrading from Ebean 19.0.0 to 19.1.0, explicitly created Database instances appear to share/collide state when they use the same logical DatabaseConfig.name, even if they are created with different JDBC URLs / different H2 in-memory databases.

This is surprising because the code does not use io.ebean.DB static access or default-server lookup. It only keeps and uses the Database instances returned from DatabaseFactory.create(config).

The same minimal reproduction passes on 19.0.0 and fails on 19.1.0.

Expected behavior

Two explicitly created Database instances with different DataSourceConfig.url values should remain isolated when accessed only through their returned Database references, even if their logical DatabaseConfig.name values are equal.

Actual behavior

On 19.1.0 both Database handles appear to operate on shared/colliding state. Rows inserted via one Database instance are visible to the other one.

Version boundary

Verified with the same reproduction:

• 19.0.0: passes
• 19.1.0: fails

We also bisected the broader line and found the same behavioral boundary between 18.0.0 and 18.1.0. My understanding is that 19.1.0 is equivalent to 18.1.0 with some features dropped, and the behavior matches that.

Minimal reproduction

I've created a minimal reproduction test here

This reproduction intentionally avoids:

• io.ebean.DB static access
• default-server lookup
• Ebean Gradle plugin
• entity enhancement
• concurrency

With io.ebean:ebean:19.0.0, the test passes.
With io.ebean:ebean:19.1.0, the same test fails with:

expected: <[first]> but was: <[first, second]>

Why this matters

In our test suite, we have hundreds of tests using

1. the same persistence configuration (DatasourceConfig + DatabaseConfig + Database) class, but a separate set of these instances and
2. the same / overlapping set of entities

When isolating these tests we rely on unique (randomized) H2 URLs, but since we're annotating the entities with the db names, we can't randomize those as well. Since we do not rely on io.ebean.DB static lookup, this have been working very well for us until the 19.1.0 upgrade. After upgrading Ebean, parallel or independent tests using the same logical database name started interfering despite having separate Database instances with distinct JDBC URLs.

If the logical name is intended to be globally unique even for explicitly held Database instances, that would be helpful to document. Otherwise, this looks like a regression in explicit Database instance isolation introduced between 19.0.0 and 19.1.0 / between 18.0.0 and 18.1.0.

AI disclosure

Both the reproduction test and an initial draft of this description has been created by GPT-5.5, but under very careful human supervision and verification.

[Incanus3]

this seems to be the culprit

[Incanus3]

and I can confirm that adding config.setRegister(false) does fix the test with both 18.1.0 and 19.1.0. so if this is the intended behavior, I guess it's not a regression, but might still trip some folks up.

[rbygrave]

So, "register [with the DB context]" defaults to true (which is kinda the original sin here) and so the previous behaviour was:

• When we register 2 instances of Database with same name ... then the "last one wins" in terms of registration with the DB Context. This was the "undesirable behaviour" the change was intended to address.

The change in 19.1.0 changed that to ...

• When we TRY to register 2 instances of Database with same name ... then we result in just the single instance in DB Context.

As I see it, this can be confusing due to the setRegister() defaults to true.

Options:

• The new 19.1.0 behaviour is deemed correct. Code hitting this needs to use setRegister(false) or use unique names
• Change again to instead throw an exception. This is more explicit that code needs to change.

---

does fix the test

To be clear, this issue occured with test code creating multiple instances with the same name (and the implied register true). Hmm.