I was wondering if you were referring to the DBManager....guess you were.
That company had another developer who wrote most of the DB manager but
since he has moved on to other things I have had to tweak it a bit to
accommodate a few additional features so I have a bit more familiarity
with it than I did when it was originally written. It is pretty simple,
really. The connection pools are tracked by what is called a role (with
a roleID). That role ID is associated with a connection with a specific
set of overrides (we use multi-membered files where the members are
different fiscal years), and library list (each role may point to a
different application set that needs different libraries). So this
isn't really pooling at the user level. It pools at the "role" level
which has the library list and file overrides which are needed. Many
users could be using the same "role" and thus using the same pooled
connection.
To distinguish between users, at login, when the role is identified and
assigned, a database record is written and a "userContainer" object in
java is created that manages user specific data for the life of the
session. UserContainers expire in about 20 minutes if they become
idle. Connection pools expire in about an hour.
I have one installation where there are about 100 concurrent users
banging on the application (a Java servlet with a JDBC connection) and
about 200 concurrent users on the RPG application using the same
database. It uses a single Tomcat instance. The LPAR it runs in has
been allocated 4GB memory and 1 processor.
If this had to scale to say, 1000 concurrent users, I am sure we'd run
out of gas somewhere. The customer is currently considering box
replacement options and they are leaning, I think, to going to a
Bladecenter H and dedicating a single blade to application serving, a
blade to traditional RPG workloads and DB serving and a blade for
development, but it is still early in the process of weighing pros and
cons of how to grow the Java workloads. The hope it to keep it simple
without investing in a "farm" (although some may see three blades as a
"farm").
BTW Nathan, the latest iteration in the company you are referring to is
to use Adobe's RIA technologies (Flex and AIR I think) to develop web
applications. I haven't seen anything new shipped in either Java or
Relational Web in the past year or more.
Pete
Nathan Andelin wrote:
From: Thorbjørn Ravn Andersen
Most likely you and your java colleagues have had many
more users than we did.
I don't know. Pete Helgren, who occasionally posts to this list would know more about it than I. He was a manager over the java team. I seem to recall that the company began imploding before most of the java applications gained much traction. The java team was laid off. The company now seems to be struggling to maintain a lot of disparate code bases.
I was wondering if you had any experiences to
share (except the one I would like to hear - namely that the
autoadjustment of OS/400 coped well with all stress situations :)
You and Walden made some good points about the scalability of this technique last week. And I don't have much information to refrute them, except the generalization that IBM i is good at managing many jobs reliability. But I have a hunch that this technique would NOT be best for a site that needed to accomodate thousands of concurrent users, who drifted in and out during the day.
Java is CPU intensive, and J2EE is really designed as a distributed architecture. It seems to me that you really need a server farm if you need to accommodate thousands of concurrent of users.
Nathan.
midrange.com
