Обсуждение: Helping application programmers catch threading bugs
Based on this thread: http://archives.postgresql.org/pgsql-admin/2009-04/msg00100.php I was wondering whether it would make sense to add a checkThreading method to help programmers who make such mistakes catch them more easily. Unfortunately I can't think of a reliable way to do this without using synchronized blocks, but maybe someone else can. In any event, I don't think we'd want to do it if there is a significant performance hit, but I bet the cost would be "lost in the noise" of measurement. Perhaps defined something like: private Thread currentThread = null; private int useCount = 0; public synchronized void checkThreading() throws PSQLException { if (currentThread != null && currentThread != Thread.currentThread()) { throw new PSQLException(GT.tr("Multithreading error; another thread is currently using the connection."), PSQLState.?); } currentThread = Thread.currentThread(); ++useCount; } public synchronized void checkThreadingExit() throws PSQLException { if (useCount <= 0 || currentThread != Thread.currentThread()) { throw new PSQLException(GT.tr("Multithreading error; invalid state found on method exit."), PSQLState.?); } if (useCount-- == 0) { currentThread = null; } } It would be used along the lines of (for example): public java.sql.ResultSet executeQuery() throws SQLException { checkThreading(); try { <existing code here> } finally { checkThreadingExit(); } } Would this be a sane and worthwhile thing to do? -Kevin
I wrote: > if (useCount-- == 0) Of course that should be: if (--useCount == 0) -Kevin
On Mon, 13 Apr 2009, Kevin Grittner wrote: > Based on this thread: > > http://archives.postgresql.org/pgsql-admin/2009-04/msg00100.php > > I was wondering whether it would make sense to add a checkThreading > method to help programmers who make such mistakes catch them more > easily. The JDBC spec requires a Connection to be thread safe. Ideally it should be able to issue queries in parallel, but PG can't do that, so we block instead. There are subtle threading bugs in the JDBC driver, but they're below the Connection level, for unusual things like executing a PreparedStatement while issuing setXXX calls on the same object from another thread. Reading the thread didn't reveal an adequate description of the actual problem, so it's not clear if there's anything to be done here or if it was operator error. Kris Jurka