Re: Persistent Sessions in DB connection for QZDASOINIT, implemented by Nathan

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.