Ming,
At 09:29 PM 6/24/99 -0400, you wrote:
>Hi there,
>
>I am involved in a project for building an EJB application that uses a DB2
>database backend and WebSphere EJB server. DB2, as most databases, limits
>the number of database connections available for database client
>applications.
>
>We will also deploy this application to WebLogic quite soon.
>
>My question is about database connection management. WebLogic states that
>there is a pre-established set of database connections, each of which could
>be shared by multiple objects. Does it mean that multi threads can share a
>single physical connection?
Yes and no. A database conection can only be used by one thread at a time.
The connections are shared between threads using a check-out/check-in
mechanism.
> Will pooling management typically be handled by EJB server?
I'm not sure what you are asking. The WebLogic server creates a pool of DB
connections (you can use almost any JDBC driver to establish the
connections) that are available for use by the application code. The
application code then uses the WebLogic "connection pool driver" (or the
WebLogic JTS driver) and calls the DriverManager.getConnection() method
(which checks out a connection from the pool) and connection.close() (which
checks the connection back into the pool). Note that the JTS driver has to
have more intellegence so that all "database work" associated with a single
JTS transaction uses the same connnection.
> Is it useful to have a central pool connection management in application
level?
> And will it be a bottleneck itself, although there are some ways to
reduce contention?
Well... I would say that, in general, it is probably not necessary to add
an application-level layer on top of the EJB server's connection pool
mechanism (not too say that it might not make sense in some cases). One
thing that can become an issue with the connection pooling approach is that
application code cannot take (full) advantage of prepared statements (since
typically they are closely coupled to the connection on which they were
prepared). If this becomes an issue, then stored procedures can be used to
address performance/contention issues.
Just my two cents,
Robert
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
