Path: csiph.com!aioe.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= Newsgroups: comp.lang.java.programmer Subject: Re: Troubles with informix jdbc driver ... Date: Tue, 15 Mar 2016 21:25:10 -0400 Organization: Aioe.org NNTP Server Lines: 67 Message-ID: References: NNTP-Posting-Host: ANasIS7Js9OyLQwgloeBLQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:33981 On 3/15/2016 6:25 PM, Andreas Leitgeb wrote: > Arne Vajhøj wrote: >> On 3/14/2016 9:54 AM, Andreas Leitgeb wrote: >>> A previous version of Informix jdbc ("3.70.JC5DE") was very >>> strict with "thread safety", in that it governed any connection >>> to any db server with a global lock. If one DB server was >>> temporarily unreachable, then it would block also connections >>> to any other db server (attempted from other threads). >>> >>> Some newer version of their jdbc driver (4.10.JC5) seems to >>> have that fixed, but we now observe that Connections obtained >>> from calling DriverManager.getConnection(...) casually get >>> mixed up! As a result, we observe threads retrieving data >>> from wrong servers - not always, but "moderately reproducible". >> >> I have never seen such a problem before. >> But let us investigate a bit. >> So essentially you have >> >> thread 1: >> Connection cona = DriverManager.getConnection(constr2a); >> >> thread 2: >> Connection conb = DriverManager.getConnection(constr2b); >> >> and sometimes you end up with the Connection object actually having >> the connection to the wrong database (different connection string)? > > Yes, that's my interpretation of what's happening at the lower levels, > based on observing the higher levels... I'll first need to come up with > an to run on my PC, then I can add further debugging aids to > determine if two threads eventually get references to the same connection, > or whether they get two separate connections for the wrongly same db-url. Unless you are using a faulty connection pool or Connection is non-local then I don't see the first as being likely. >> As if there somewhere deep down in the driver code were a static field >> being overwritten. >> That would be easy to test by just putting: >> synchronized(DriverManagager.class) { >> } >> around all the getConnection calls. > > Like Marcel in his follow-up, I can't quite see how that could > help me locate the bug. It may help convince IBM that it indeed it is a bug in their code. > It would probably "fix" the bug, but > get me back to what I had with the old driver, namely the problem > that a single bad connect will - until timeout of the tcp-connect - > block other threads from connecting even to other&alive servers. True. But if you have an unreliable connection between the application and the database, then I think you should fix that. Because it would not just impact connect but everything else as well. It will never work well. Arne PS: Have you considered biting the bullet and switching to using a connection pool? It would probably fix all your problems!