× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.