Derek Conniffe wrote:
> Hi All,
>
> I've been working with JSP for about a week now & so far so good!.
>
> (Like a large number of people) I'm most interested in using JSP to create
> dynamic pages with contents provided via. a database connection.
>
> I've written the JSP Beans which handle the database connection & again - so
> far so good.
>
> I have difficulty in understanding how to produce a bean that is more than
> simply session-wide - I need a bean that has one constant-state database
> connection that JSP files can use - otherwise each and every session would
> require a new database connection & after an amount of time you would
> imagine a large number of connections would exist.
>
> Is this linked to the "session" / "application" scope argument when using
> beans in a JSP file?
>
Yes, application scope is what you want to use for sharing. Anything stored
here is visible to all servlets and JSP beans that use the same servlet
context. In fact, if you also use pure servlets in your app, these objects are
visible by calling:
getServletContext().getAttribute("bean_id");
where "bean_id" is the same string you would use in a <jsp:useBean
id="bean_id" ... /> tag to refer to this object.
Rather than a single connection, though, I would recommend that you use a
connection pool instead (there are several open source ones around). Among
other things, this avoids problems of a database transaction (ending in COMMIT
or ROLLBACK) from one user affecting the in-progress transaction of another
user. That way, whenever a particular pgae needs to do some database work, it
would:
* Allocate a connection from the pool
* Use that connection for its work
* Return that connection to the pool
The total number of connections you need to configure in your pool is the
expected maximum number of simultaneous accesses, rather than the total number
of users. Thus, you consume a lot less database resources this way than a
connection-per-user model does.
>
> How is threading handled in this case?
>
>
Dealing with multithreading is the developer's responsibility, as usual. But
connection pool beans will deal with it for you in their "allocate" and
"deallocate" methods. While you have an allocated connection, it is solely
being used by the thread that is responding to that particular request, so you
don't have to worry about it -- just be sure to give the connection back to the
pool before you finish processing this page.
> Thanks,
>
> Derek.
>
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
