Re: Persistent Sessions in DB connection for QZDSAOINIT

Similar to what I did as well with the DBManager class. We store the "RoleID", which in essence is a reference to the connection pool (the ID-pool is in a HashMap) in this userContainer object as part of the session. Whenever we connect to the database, we just call a "getConnection" method which is session aware and it retrieves the pooled connection and uses it to connect. Overhead is only incurred the first time that the connection is created for the role. Subsequent connections use the pooled connection.

Not sure there is a "way to do things" here. Any technique that reuses an "expensive to make" resource seems a smart approach.

Pete


Richard Schoen wrote:

I haven't been following this thread, but I have used a JSP technique
where I have wrapped the JT400 classes in a Java object and then stored
the Java object in the JSP session. I have used the same technique in
.Net as well.

This is a nice way to maintain the same DB connection across page
interactions without incurring startup cost for each page get/post.

This technique may not be viewed by some as the "way to do things".
However it works well and performs very well because you avoid the
connection start penalty for each interaction and the user gets the same
DB and program call connections across pages.
I find there's always a tradeoff between the "way to do things" and what
works and performs well.
Regards,
Richard Schoen
RJS Software Systems Inc. "Get the information you need. Now!"
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT


-----Original Message-----

------------------------------

message: 3
date: Sat, 25 Oct 2008 15:11:45 -0700 (PDT)
from: Nathan Andelin <nandelin@xxxxxxxxx>
subject: Re: [WEB400] Persistent Sessions in DB connection for
QZDASOINIT, implemented by Nathan

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.