My humble 2p worth...
In your rebuild, perhaps you might consider avoiding the built-in session
vars altogether. After getting caught with them in ASP a few years ago I
vowed to avoid them altogether. My latest JSP app implements pseudo-session
vars via a few classes and a db table, which takes
In practice, the load on the DB is the killer right?
atleast in my experience, that is the killer unless you use a good database like
sybase, db2 or oracle. my .2 cents.
peter lin
[EMAIL PROTECTED] wrote:
My humble 2p worth...
In your rebuild, perhaps you might consider avoiding the
Disable all of the auto reloading features of tomcat. The mem leak
seems to be centered there. Or at least, I haven't had a OOME since I
turned that stuff off.
You would need clustered sessions of some sort. They either need to be
persisted across the network using filip's code (tomcat 5 has
Peter Lin wrote:
snip
In practice, the load on the DB is the killer right?
/snip
Peter,
I have no personal experience, but that's what the docs that I've read say -
the db access becomes the limiting factor.
One further advantage of db-based session vars is that you can see in
real-time what
My experience is the same.
hope it helps
-reynir
Angus Mezick wrote:
Disable all of the auto reloading features of tomcat. The mem leak
seems to be centered there. Or at least, I haven't had a OOME since I
turned that stuff off.
You would need clustered sessions of some sort. They either need
Derek Clarkson wrote, On 3/15/2004 10:32 PM:
We have an app written in a mix of JSP, servlets and struts across 3
instances of apache, tomcat and an RMI server. To say that it's a pile of
smelly stuff is an understatement, however it works (mostly) and our
customers depend on it. At least once a
Hi,
To keep it up, you will need to setup session replication (See your
Cluster element in server.xml), either in-memory or JDBC. Both are
supposed to work.
However, that implies several things:
- Your session must contain Seralizable objects only.
- Your performance will be worse (how much