Will future versions of MyBatis officially support multi-threaded or asynchronous ResultMap processing?

[worldbright]

For performance reasons, I have avoided using XML-based ResultMap definitions in MyBatis. Instead, I have implemented a custom mechanism that issues multiple queries in parallel—using threads & connections—and manually sets the results onto target objects. This allows me to mimic the multiple select queries in ResultMap, but in a highly performant, concurrent manner.

Since Java 21 introduced Virtual Threads as a preview feature (and now stabilized), the performance and scalability of this approach have improved significantly. It enables lightweight concurrency with minimal overhead, making parallel query execution much more feasible, even at scale.

Of course, I fully understand that MyBatis needs to maintain compatibility with Java 8 and 11, which makes it difficult to adopt Virtual Threads directly at the framework level for now. However, the current design of ResultMap—which executes nested queries sequentially—creates a serious performance bottleneck for applications with deep or complex object graphs (e.g., 1:N:N relationships).

I’m wondering if there are any plans (or openness) to support an optional, thread-enabled (multiple-connections) ResultMap processing model in the future. Even if it relies on physical threads (e.g., Executors, ForkJoinPool, etc.) rather than Virtual Threads or coroutines, the ability to fetch nested results concurrently would provide a massive performance gain in certain scenarios.

I understand that thread safety, transaction management, and potential deadlocks are valid concerns. However, the Java ecosystem has matured significantly in this area. Modern applications are increasingly concurrent by nature, and frameworks like Project Loom have pushed concurrency to the forefront. I believe MyBatis should consider adapting to these evolving patterns.

I realize this may sound like a bold or non-traditional request. Still, I’d love to hear the community’s thoughts on whether something like this could be feasible—either as a core feature or as an opt-in extension.

[harawata]

Hello @worldbright ,

I don't think they will.
I'm not sure what "mimic the behavior of nested or joined mappings" means exactly, but both java.sql.Connection and java.sql.ResultSet are not thread safe.

[worldbright]

I updated it to:
"This allows me to mimic the multiple select queries in ResultMap."

When executing multiple queries in parallel, each thread should have its own Connection and ResultSet.
So I believe thread safety shouldn't be a concern in that case.

[harawata]

Nested queries should be executed using the same Connection as the parent so that they belong to the same transaction (unless they are marked as "lazy").
It would be obvious, but changing this behavior will break backward compatibility.

Also note that MyBatis uses local cache to prevent the same query (identified by statement id + parameter) from being executed multiple times.
MyBatis won't be able to utilize local cache if each nested query is executed in a different session.

[worldbright]

In my case, the data I’m combining is entirely independent, so it’s acceptable that they are not fetched within a single transaction. That’s why it’s feasible to run those queries in parallel using separate Connections.

That said, as you pointed out, when nested queries need to be executed within the same transactional context, they must share the same Connection and be executed sequentially. I missed that important consideration—thank you for pointing it out.

What I’m suggesting is that, for independent data that can be safely queried in separate transactions, it would be helpful if MyBatis provided an optional way to allow those nested mappings to be fetched in parallel. This would give developers more flexibility based on their specific use case.

[epochcoder]

@worldbright With properly configured nested results, there should not be a reason to issue more than one query. MyBatis can map complex objects based on the results from one query only. If performance is the goal, issuing more than one query for every row is not an ideal case. This can be solved in most cases by good design and using nested results for each query.

While i'm not dismissing the request, I believe it should not be necessary in the first place to do that if the design follows good principles.

[worldbright]

I’ve often used the following pattern when referencing a select query from another Mapper,

<collection property="fieldname" column="pk" select="select query from another mapper">

My intention was to reduce duplication and improve maintainability by separating responsibilities into individual Mappers.

But in such cases, it might indeed be better to handle everything within a single SQL query, possibly using subqueries or joins, even if it means crossing responsibility boundaries temporarily. While I initially avoided this approach due to maintainability & duplicate code(query) concerns, your point helped me reconsider. It may be a valid trade-off in certain contexts.