I have a table with a few thousand columns. The table changes frequently but only through hibernate (My application is the only application using this database). I have observed that hibernate does not use its cache to run queries after the table is updated.

It seems to me that since the table updates also go through hibernate, hibernated always has the latest data and it should be able to run the queries in memory without hitting the database.

For small tables, that could be loaded in memory and are only accessed by one application, if hibernate could run queries in memory then that would be useful in many applications.

Could you tell me if this feature is already supported or if there are plans to implement this feature?

I meant "I have a table with a few thousand rows".
Sorry about that.

No, this is way much complex than that. DB can do stuff behind you back (trigger), or queries results based on criteria can evolved because of your update.
Hibernate is not a DB.
You can copy your data to a memory DB such as HSQLDb.

I agree with your point about triggers.

I think that if application developers feel that there are some tables that can be safely loaded into memory then they should have that option. Something like

Wouldn't you get this functionality by using 2nd-level caching?

No. 2nd-level caching does not implement this functionality.

To explain why, let's consider 2nd-level caching with query cache and without query cache.

(1) Without query cache:
Hibernate asks the database to run the query and uses its second level cache to load objects.

(2) With query cache:
Hibernate loads query results from its second-level cache. If any of the tables in the query were modified since the query was run then Hibernate will discard the query results and ask the database to run the query again.

Clearly, in both cases, Hibernate makes or is likely to make database calls.

This approach makes sense for many cases.

But as I pointed out in my previous post, there are applications where this approach leads to a fair number of unnecessary database calls. An attribute like "load-table-in-memory" would allow developers to gain substantial performance improvements for such applications.

my second argument stay correct.