At 09:01 рм 6/9/2000 -0600, you wrote:
>Filippos Slavik wrote:
> >
> > At 07:04 рм 6/9/2000 -0600, you wrote:
> > >Chin Cedric Sung Kit wrote:
> > > >
> > > > i initialize my oracle-jdbc
> > > > database connection in my LoginServlet. how do i re-use this
> connection
> > > > in my other jsp pages, so that i will not have to open so many
> > > > connections?
> > >
> > >You don't re-use your connection. At a minimum, you should use a new
> > >connection for every session. If you try to use the same connection for
> > >every request, you will have concurrency problems.
> >
> > This is completely wrong. You can share a single java.sql.Connection
> > instance among many threads. Synchronization issues appear in the context
> > of java.sql.Statement instances, which again can be shared among many
> > threads but with care.
>
>Not at all. With one connection, how do you handle this situation:
>Thread 1 -> conn.setAutoCommit(false); ---------------------------->
>executeUpdate()
>Thread 2 -------------------------------> con.setAutoCommit(true)
>
>Thread 1 sets autocommit to false. Thread 2, using the same Connection
>instance, sets autocommit to true. Thread 1 attempts a long set of SQL
>statements.
You're right about that. But on the db engine (which is not just connection
pool) I'v implemented for my needs, I have reached a certain higher-level
usage over the jdbc API. I'm just not providing any kind of jdbc API call
possibility. Furthmore the commit mode is set implicitly to false.
>I would also question your claim the Statements can be shared with care.
>Maybe it is possible if one is using Statements for executeUpdate which
>returns an int value. In that case, you can synchronize those one or two
>statements. However, if you are using the Statement to get a ResultSet,
>you should use separate Statements. You could synchronize, but that's
>the same as doing everything serially. Why should thread 2 wait for
>thread 1 to finish using the ResultSet, especially if it's a scrollable
>result set? (At least with oracle jdbc 1.0. The Statement object uses
>the same ResultSet object for every query.) It's just as easy for thread
>2 to get its own Statement object.
In my previous post, I wrote "can be shared among many threads but with
care.". I did not said concurently. Offcourse the ResultSet's obtained from
the Statement instances are processed in a serially matter, so any other
thread waiting for the *concrete* Statement has to wait until any other
thread finishes working the ResultSet obtained from this very Statement.
Ofcourse there is a wait penalty, but:
[1] I have several Statement instances for each Connection I manage.
[2] In some cases and always talking for my environment the wait penalty
for a free Statement instance (if there are no more left) is not
significantly longer than the wait penalty required to create a new
Statement instance.
*) Also I never let the caller to work with a ResultSet, I always return
him a holder class -> so the ResultSet's instance life-cycle is limited as
much as possible
> > I have personally build a db engine implemented as singleton to be used and
> > shared among many servlets running under the same JVM process. The db
> > engine opens a certain amount of connection to the database subsystem (2-3
> > are just enough) and share them to all running threads, which in the case
> > of servlets may be quite a lot!
>
>Oh, you created a Connection Pool, and while connections are shared,
>they are not CONCURRENTLY shared. Sure, I agree that connections can be
>re-used. But the original question did not ask how to use pooled
>connections or how to reuse a connection; the original question asked
>how to use a SINGLE connection in multiple JSP servlets.
As I'v already wrote, It's not a simpe connection pool. The "framework" i'v
implmented hiddes all jdbc specific API calls from the "end-user" or
"client". But you're right , connections are not "concurrently" shared,
they are *JUST* shared in a thread-safe manner. But since each
"connection" has a "repository" of available Statements ... there is a
certain degree of concurrecny here.
I stop here, since I feel that I became quite ego-centric and I'm actually
described how I'v implemted certain things.
>I sent this to another poster yesterday (I sent it privately, so it will
>not be in the list archive):
>
>"If your application is using the most up to date JDBC features, you
>should get your connection from a DataSource object. Check the advanced
>tutorial at http://java.sun.com/products/jdbc/learning.html for
>information about a DataSource. If you can't use a DataSource, then the
>next best thing is to use a connection pool. Most servlet books address
>connection pools. As a last resort (or if connection creation time is
>not an issue), create a new connection for every request to the
>servlet."
I'll read that :-)
>I still stand by my original post: One should not use a single
>Connection for every request to a JSP/servlet.
>
>K Mukhar
Best Regards
Filippos Slavik
################################################################
Filippos Slavik
Forthnet R&D, Hrakleio, Greece
e-mail : [EMAIL PROTECTED]
phone : (+3) 081 391230
################################################################
"The software said 'runs on Win95 or better,' so I installed it
on Linux..."
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
