Tomcat 5.5.7 using builtin JDBC connection pool, can't access 'real' connection - accessToUnderlyingConnectionAllowed=true

[Bernd Bartke]

Hi there,
did anybody manage to access the underlying 'real' database connection?
I have got to use the PostgreSQL LargeObject API and therefore I need access to 
the delegated connection.
But after several hours of trial and error I lost my motivation ... It seems 
like:
- doesn't do anything:
Resource ... accessToUnderlyingConnectionAllowed=true .../
- always returns 'false':
org.apache.tomcat.dbcp.dbcp.PoolingDriver.isAccessToUnderlyingConnectionAllowed()
 .
- doesn't do anything:
org.apache.tomcat.dbcp.dbcp.PoolingDriver.setAccessToUnderlyingConnectionAllowed(true);
- also doesn't do anything:
dataSource.setAccessToUnderlyingConnectionAllowed(true)
At last I found some kind of workaround, which is indeed not really desirable 
...
Accessing an org.postgresql.PGConnection via a statement works ...
Maybe someone can help me.
Bye,
Bernd.
code snippet:
import org.apache.tomcat.dbcp.dbcp.PoolingDriver;
import org.apache.tomcat.dbcp.dbcp.BasicDataSource;
import org.apache.tomcat.dbcp.dbcp.DelegatingConnection;
import org.apache.tomcat.dbcp.dbcp.DelegatingStatement;
import org.postgresql.PGConnection;
...
logger.debug(PoolingDriver.isAccessToUnderlyingConnectionAllowed: 
+PoolingDriver.isAccessToUnderlyingConnectionAllowed());
PoolingDriver.setAccessToUnderlyingConnectionAllowed(true);
BasicDataSource dataSource = (BasicDataSource)envContext.lookup(jdbc/website);
logger.debug(dataSource.isAccessToUnderlyingConnectionAllowed: 
+dataSource.isAccessToUnderlyingConnectionAllowed());
dataSource.setAccessToUnderlyingConnectionAllowed(true);
logger.debug(getting delegating connection);
DelegatingConnection connection = 
(DelegatingConnection)dataSource.getConnection();
logger.debug(getting 'real' connection);
logger.debug(connection.getDelegate():  + connection.getDelegate());
logger.debug(connection.getInnermostDelegate():  + 
connection.getInnermostDelegate());
// for some reason this works:
DelegatingStatement stmt = (DelegatingStatement)connection.createStatement();
PGConnection pgCon = (PGConnection)stmt.getDelegate().getConnection();
stmt.close();
logger.debug(pgCon);
..
corresponding output:
PoolingDriver.isAccessToUnderlyingConnectionAllowed: false
dataSource.isAccessToUnderlyingConnectionAllowed: false
getting delegating connection
getting 'real' connection
connection.getDelegate(): null
connection.getInnermostDelegate(): null
[EMAIL PROTECTED]
my configuration:

server.xml:
- no pooling stuff in here -
WEB-INF/web.xml:
web-app
...
  resource-ref
  descriptionDB Connection/description
  res-ref-namejdbc/website/res-ref-name
  res-typejavax.sql.DataSource/res-type
  res-authContainer/res-auth
  /resource-ref
...
/web-app
META-INF/context.xml:
Context ...
...
  Resource name=jdbc/website scope=Shareable type=javax.sql.DataSource
auth=Container 
factory=org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory
url=jdbc:postgresql://host:5432/website
driverClassName=org.postgresql.Driver username=tomcat 
password=***
defaultAutoCommit=false defaultReadOnly=false
defaultTransactionIsolation=READ_COMMITTED initialSize=1 
minIdle=1
maxWait=1 maxIdle=10 maxActive=20 
accessToUnderlyingConnectionAllowed=true
validationQuery=select 1
  /
!-- forget it ... also has no effect
  ResourceParams name=jdbc/website
parameter
  nameaccessToUnderlyingConnectionAllowed/name
  valuetrue/value
/parameter
  /ResourceParams
--
/Context
java 1.4.2_07
tomcat 5.5.7
PostgreSQL 8.01

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Rejecting connections: empty http header if maxProcessors reached

[Bernd Bartke]

Hi,

what is the desired behaviour if tomcat 4.1.29 rejects incoming requests 
because of maxProcessors reached?
Should tomcat return an empty http header?

To simulate the expected load on tomcat 4.1.29 I wrote a java client 
which starts conurrent threads accessing the web resource:

...
HttpURLConnection connection;
URL request;
InputStream input;
...
connection = (HttpURLConnection)request.openConnection();
input = connection.getInputStream();
...
When getting the input-stream out of the connection an IOException is 
thrown if maxProcessors is reached.
That seams ok for me, but how can a client determine if a real 
exception occured or the server rejected a connection?
I tried to look into the http-header of the connection:
...
Map headerFields;
...
connection = (HttpURLConnection)request.openConnection();
headerFields = connection.getHeaderFields();
...

But the header does not contain any fields ... an empty Map is returned.
Is it really the desired behavior of a server to return an empty header 
or shouldn't it better return at least an response code indication the 
rejected request?

I think a client should at least be able to call:
...
int responseCode = connection.getResponseCode();
...
to evaluate the response code - but if the header contains no fields, an 
IOException is thrown also.

Bye.


smime.p7s
Description: S/MIME Cryptographic Signature