From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Mauro Molinari <mauro(dot)molinari(at)cardinis(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: BUG #5177: Concurrency problem in AbstractJdbc23PooledConnection |
Date: | 2009-11-18 14:29:50 |
Message-ID: | alpine.BSO.2.00.0911180924040.19001@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-jdbc |
On Tue, 10 Nov 2009, Mauro Molinari wrote:
> Bug reference: 5177
> PostgreSQL version: 8.3.8
> Description: Concurrency problem in AbstractJdbc23PooledConnection
> Details:
>
> Hello, we're using PostgreSQL JDBC3 driver 8.3-605 to connect to a 8.3.8
> Postgres instance. Our application has a JTA-XA transaction infrastructure
> managed by Spring and using JBoss Transactions as a JTA implementation.
> We're using a connection pool of our own to pool XA connections on top of
> which there's JBoss Transactions transactional driver that is managing
> connections. Our connection pool infrastructure creates a PGXADataSource
> from which it gets new XA connections.
>
> In this scenario, sometimes happens that the PostgreSQL driver fails with
> the following exception:
>
> java.lang.NullPointerException
> at
> org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$ConnectionHandler.in
> voke(AbstractJdbc23PooledConnection.java:319)
> at $Proxy5.close(Unknown Source)
> at
> com.arjuna.ats.internal.jdbc.ConnectionImple.close(ConnectionImple.java:369)
>
> Looking at the JDBC driver source code, it seems a concurrency problem,
> because at row 304-305 the variable con is checked against null.
>
> What is actually happening here is that our code is closing a connection
> used to read some data from the DB. This read operation is executed outside
> any transaction, so JBoss Transactions is honouring the connection close
> request by first calling calling close on the XA connection (and this is
> causing the XA connection to be given back to our pool); after that, because
> of the actual JDBC connection reports false on isClosed(), JBoss
> Transactions is also calling close() on it too... and this generates the
> NullPointerException given above.
>
> Looking at the AbstractJdbc23PooledConnection it seems there's no
> synchronization at all between isClosed() and close(). My suspect is that in
> the previous scenario something like this happens:
> 1. thread 1: close() is invoked
> 2. thread 2: isClosed() returns false
> 3. thread 2: close() is invoked
>
> At operation 2., isClose returns false, while it should return true because
> a close request has already been made on thread 1. Anyway, there should be
> no problem at all to call close repeatedly on the same connection (as the
> JDBC contract states), so the NullPointerException should not happen in any
> case.
>
Attached is a test case which reproduces this problem easily.
> Thanks in advance and please let me know how I can monitor this bug report
> (is there any bug tracking system for PostgreSQL?).
>
There is no bug tracker for postgresql in general. The JDBC driver does
have a bug tracker, but the mailing list is where most of the action
happens.
http://pgfoundry.org/tracker/?group_id=1000224
Kris Jurka
Attachment | Content-Type | Size |
---|---|---|
XaCloseTest.java | text/plain | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-11-18 15:47:10 | Re: psql command line variables are unknown when -c SQL statement are executed |
Previous Message | Boris Folgmann | 2009-11-18 09:56:12 | Re: BUG #5151: autovacuum process segfaults when max_fsm_pages are too low |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-11-18 19:31:32 | Re: commit and rollback don't throw exceptions when they should |
Previous Message | Kris Jurka | 2009-11-18 11:21:38 | Re: commit and rollback don't throw exceptions when they should |