Session limitation for saving data

It does not have a question of being too much for the session. It may be too much for the memory you have available. If you have 600 records in the session. It's too little. If you have 1000 concurrent sessions, 600,000 can be a lot. It may not be.

I I answered something about this . There I say that the best solution is a caching system. It is most suitable in most situations because it can be released if necessary and lasts beyond sessions, which in many scenarios can be an interesting gain. There I say not to exaggerate the load of session . But I say exaggeration. And the size of the overstatement depends on the available memory.

Remember that the database has a cache too (see how to implement the OnoSendai response). It might be enough, too. Measured to see if you really need to keep something in memory? Is it a reasonable gain? Without measuring, you can not say anything. Even if it is intuitive, sometimes, in practice, something different than expected may occur.

If you find that you need another cache level, look for an in-memory solution on the same server. This should solve 99.99% of the cases. If you have a rare case at hand and need to scale horizontally, look for software that helps with this, like a Memcached , Redis , etc.

There's a framework that helps with this and has several options. On their page, it confirms that the simplest cache is the fastest and that databases serve the most when there is a need for cross-process distribution (where performance is absurdly low, to the extent that it is not very useful as a cache in some scenarios). The use of dictionary is also the one that takes up less memory, which is useful to make room for more useful content.

  

The average number of records returned is 600, is it too much for a Session?

No. Sessions in theory have no storage limit.

  

Would you have any other better way to save this data?

Yes, on a key-value presence server, such as Redis . Sessions limit you to only one server, whereas Redis can serve you in a distributed context.

As Gypsy and bigown have said, no, there are no limits.

But if your problem is performance in an Oracle database, I have a suggestion: Materialized Views .

A Materialized View is basically a snapshot of a query cached in the database, which can be indexed.

This is an example of creating Materialized View :

CREATE MATERIALIZED VIEW MV_LOGINS_USUARIO_52
NOLOGGING
CACHE
BUILD IMMEDIATE 
REFRESH FAST ON COMMIT 
AS
[Sua query aqui]

Once created, the view will contain the result of the last query until it is destroyed or refreshed. Since you are not executing the query again, but only accessing cached data, the response time is much higher.

The advantage of this method is that you do not consume web server resources.