Yep, memory is probably the primary drawback. However in today's world
memory can cure a lot of ills.

Witness the new 3-4gb laptops to run Vista :-)

In the case of a JSP application the cool thing is that this technique
can scale quite nicely to several thousand users by adding another Intel
or Linux box to run the application or it can all be run on the "i". It
all depends on the user needs.

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: Sun, 26 Oct 2008 15:38:20 -0500
from: "Aaron Bartell" <aaronbartell@xxxxxxxxx>
subject: Re: [WEB400] Persistent Sessions in DB connection for
QZDSAOINIT

I think the issue most would have with that is the JDBC connection is
being stored in an HTTP session object which in turn is taking up
memory. So as long as your memory is up to snuff you shouldn't see
issue with this.
Anybody please correct me if I am wrong. I would be curious to know
if/when the HTTP sessions objects get paged out of memory to disk. In
theory this would then facilitate your approach quite nicely and only
when a stale HTTP session was being re-activated would a user notice a
lag in their session.

If the situation doesn't require that you build for a 1000+ user
scenario then I am also one that takes shortcuts here and there even
though they might not be the purist approach.

Aaron Bartell
http://mowyourlawn.com

On Sun, Oct 26, 2008 at 3:00 PM, Richard Schoen <richard@xxxxxxxxxxx>
wrote:


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.