>> >> If you want to improve performance even more, ditch EJB altogether. >> Moving from APR to NIO may be a good move, but it really depends upon >> your requirements. For instance, APR provides superior SSL performance >> but if you don't need it, NIO will probably give you better results. >>
Understood, thanks Chris. For now, only office personnel is accessing the web app behind a firewall, and others (including myself) access via laptop and mobile devices outside of the office via HTTP, so NIO is sufficient for now, until I'm ready to go HTTPS/SSL via APR. >> That depends upon what you want to accomplish. You can get messages >> about JDBC resource management problems without writing any >> interceptors at all. >>>>> Okay, well, I'm using JPA to access JTA managed datasource (Apache Derby), and I really don't think I have any JDBC resource management issues. >> >> That depends upon what you mean by "clustering". If you want to serve >> more clients (or have fault-tolerance), then "clustering" is a good >> idea. "Clustering" means different things to different people. If you >> just want to scale horizontally (more app servers) and use simple >> load-balancing, that can be considered a cluster. > For now, I want a cluster of at least 2 or 3 tomcat servers for fault-tolerance and load balancing. > > When I mention thread programming, I mean WebApps that start (Java) threads > to do background work, like import data, send automatica notifications, and > so on. I know it is a (almost) bad practice to have web apps creating > threads, but this is so common in real world enterprise apps! > Yes, I read that it is not good for web apps to start (Java) threads to do background work, and per that advise, I have avoided that for now. so far, I have used @Asynchronous and @Schedule, very minimally. > >> >> In the Java world, most people would only call it a consider it a >> "cluster" if the app servers actually know about each other -- for >> instance, if you are using session replication. IMO session >> replication is a dog, and there are better ways to achieve similar >> goals that yield much higher performance. Chris, I'm glad you mentioned, "IMO session replication is a dog", because honestly, I would love to avoid some of the pre-work required to prepare my app for session replication. I'm definitely interested in the 'better ways to achieve similar goals. I would love to have 2 or 3 instances of my web app accessing one database (Derby, at the present), and all 2 or 3 instances actually knowing about each other. :) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
