Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (asf.osuosl.org: domain of matt.koranda@edb.com designates
 212.18.128.227 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Connection hangs with SQL query string 1983 of length,
 can this be a SQLMap bug ?
Date: Wed, 7 Sep 2005 14:39:42 +0200
Message-ID: <6D8222F55B8A004FB28713CC2104F9D287A358@EDBCL01CN011.EDB.local>
Thread-Topic: Connection hangs with SQL query string 1983 of length,
 can this be a SQLMap bug ?
Thread-Index: AcWzphaeg93++a2PQlq/M26lBTcphQAAvKVQ
From: "Koranda Matthew James" <matt.koranda@edb.com>
To: <user-java@ibatis.apache.org>,
	<lmeadors@apache.org>

I agree with the driver advice, classes12 is pretty old, have you tried
ojdbc14.jar?

Matt=20

-----Original Message-----
From: Larry Meadors [mailto:larry.meadors@gmail.com]=20
Sent: 7. september 2005 14:17
To: user-java@ibatis.apache.org
Subject: Re: Connection hangs with SQL query string 1983 of length, can
this be a SQLMap bug ?

Wow, that is a wacky one..it seems most likely that it is a driver issue
(i can promise that there is no "if(sql.length() =3D=3D 1983) =
blowChunks();"
code in SQL Maps.

Can you try it with the latest Oracle drivers? From all reports, the 10g
drivers resolved a ton of bugs that were popping up.

It might not hurt to update to a more recent iBATIS build, too.

Larry


On 9/7/05, erlend.bjorge@aftenposten.no <erlend.bjorge@aftenposten.no>
wrote:
> Hi there!
>=20
> When digging for the error in my previous message:
>=20
>     "Possible to set timeout on the connection ?"
>=20
> I came over a very strange bug somewhere from SQLMap, the Oracle=20
> driver classes12.jar and to the database Oracle 9.2.
>=20
> I do a plain SQL without binding variables (I do $complexWhere$ ->=20
> myBean.geComplexWhere) in the xml file) the query looks like this from
the debug info:
>=20
> DEBUG 2005-09-07 11:55:50,003
com.ibatis.common.jdbc.logging.PreparedStatementLogProxy (Line: 48) -
{pstm-100007}
> PreparedStatement:          select C.COMPANYID, C.DMID, ..........
where ...
>                                     and (( C.ORGANIZATIONNO like
'%Galleri Henrik%'
>                                     or  lower(C.BUSINESSNAME) like
lower('%Galleri Henrik%')
>                                     or  lower(C.MARKETNAME) like
lower('%Galleri Henrik%') ......) ) )
>                             order by  .....
>=20
> DEBUG 2005-09-07 11:55:50,023=20
> com.ibatis.common.jdbc.logging.PreparedStatementLogProxy (Line: 49) -=20
> {pstm-100007}Parameters: [] DEBUG 2005-09-07 11:55:50,033=20
> com.ibatis.common.jdbc.logging.PreparedStatementLogProxy (Line: 50) -=20
> {pstm-100007} Types: []
>=20
> (mine lineshifts in the query, and mine replacments of sql with .....)
>=20
> ---
>=20
> The query string is of 1983 length (if you count the spaces before the

> "select" statment), or 1973 without the spaces, no tail whitespaces=20
> counted. When I search e.g. for 'Galleri Henrik', the query string get
exactly total 1983 of length. But lets say it's 1983 then.
>=20
> SO WHEN the query string is of exactly 1983 of length the SQLMap=20
> connection hangs and I get some kind of lock in the database (CURSOR=20
> BIND). Believe it or not !!! I still can't believe it :-)
>=20
> One Oracle guru told me that the case could be that Oracle are not=20
> able to return the result back again after doing this query and goes
into somekind of wait modus. Waiting for "something"
> for the connection ?? I don't have a clue.
>=20
> It's nothing wrong with the data or the SQL. I can copy&paste this=20
> query string into a SQL tool, using the same Oracle JDBC driver as=20
> SQLMap does (I use DbVisualizer), and run the query with or without
the whitespaces in front, and the query runs just fine under 1 second.
>=20
> This make me think, can this has something with SQLMap to do ? Do=20
> SQLMap somekind of string manipulating that could result in some kind
of "modus" when the query string is of 1983 in length ?
> Oracle can handle more then that of course and should be discovered=20
> for a long time agao if that was the case ? Same with the driver, but
what about SQLMap ??? A bug ?
>=20
> It's a actually unbelievably this case, when the query string is less=20
> or larger than 1983, no problem at all, makes it even more strange. As

> my previous e-mail, when size is 1982 or 1984 no problem, And it's not
related to Galleri Henrik .. I can typ in '1234567 123456' -> same
error, it's the length !!
>=20
> --
>=20
> Have you heard of this before ? :-) Any wild ideas ?? Something I
should test ?
>=20
> --
>=20
> The quick solution is to remove many whitespaces in the sql string =3D =

> become less that 1983 of length with normal searches. Not that quick
is to make binding variables.
> Tested both, works just fine.
>=20
> We use the SQLMap version available in january 2005.
>=20
> Clues ?
>=20
>=20
> Cheers,
> Erlend
>