Same BeanDescriptors causes lots of memory usage for multitenancy

[lera12518]

We've faced a problem using multi-tenant architecture.

Every our tenant has its own database with same schemes, tables and columns inside. We create Ebean server object for each tenant with same model packages. So every tenant has its own copy of BeanDescriptor array with same models. We have hundreds of simultaneously working tenants so this lead to large consumption in heap memory.

The question is, can something be done with this? Maybe BeanDescriptorManagers of different Ebean servers could somehow share BeanDescriptor of identical models so that they are not duplicated in memory?

Thanks in advance.

[rPraml]

We did the same years ago and had the same problem. Now we use one ebean server and a multitenant datasource.
Now we have only the problems, because we have one connection pool per tenant - and roundabout 150 tenants with 10-20 connections each brings the database to its limit.

My advice is to use one ebean server with the multi tenant support from ebean with an appropriate datasource. I currently do some research with DB2 and trusted context to reuse connections with an other user id...

[jnehlmeier]

We also use just a single Ebean database but with one DataSource (connection pool) per tenant. See Ebean's TenantDataSourceProvider, CurrentTenantProvider and TenantMode.DB. There is also TenantMode.DB_WITH_MASTER but I don't use it because I have no clue which benefits it provides. TenantMode.DB works fine.

However we use dynamic sized connection pools so we do not have so many unused open connections lingering around. With good hardware the cost of connection creation is negible in our case. Tenants are spread across multiple database servers so we do not run in the situation that a single database struggles because of the number of concurrent connections.

[lera12518]

@rPraml @jnehlmeier Thank you for your answers and advises. We will explore these options.
We also have dynamic sized connection pools and tenants are spread across multiple db servers. So when connection is unused for a while we close it.