|
Lei,
Not sure about a way to limit the session size in a
particular container. However, best practice is to keep HTTPSession as
small as possible for each user. If configured for persistent session, remember
it will get serialized and stored, so from a query and store perspective the
larger it gets the slower it will be to perform these operations. When you get
into a clustered configuration, you may have in-memory session replication for
fail over, or just persisted as noted before.
So to answer you question, you need to get familiar
with what is being done with HTTPSession in your particular container
configuration. Then if the HTTPSession behavior (persistent, replication, etc)
is consistent with the behavior required for the cached data, there is no
advantage to building another cache. If the data does not have the same
requirements, then yes there may be advantage to creating another cache.
Regardless of what is chosen, you will still have to performance profile the
application to see how its behaving, and ultimate tuning of the JVM is always a
good idea.
Best
Regards,
Tom --
|
