db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Eade <se...@backstagetech.com.au>
Subject Re: Village API: Doing unprepared SELECT before UPDATE and how to fix it
Date Mon, 08 Dec 2003 22:19:52 GMT
Instructions for accessing the Village source are at:


I just tested anonymous access and it works fine for me.


Scott Eade
Backstage Technologies Pty. Ltd.

Göschl,Siegfried wrote:

>Hi folks,
>I had a look at the discussion about Village API using an unprepared SELECT statement
before doing an UPDATE which could potentially crash an ORACLE database. And the Oracle DBA
are not particularly nice around here if you crash a production database ... :-)
>1) I'm currently using Torque 3.1 with Oracle 9i
>2) I'm not able to get the Village source code since the CVS server is not running/down/whatsoever.
>3) The trouble is located in DataSet.fetchRecords(int,int) - I don't know if this is easy
to fix since I only have decompiled source code and the JAR which my WSAD doesn't like stepping
through (I know real programmers don't use a debugger ... core dump is just fine)
>3.1) TableDataSet.fetchRecords() builds a select string using its member variables and
delegates the work to DataSet.fetchRecord() 
>3.2) DataSet.fetchRecord() has no other chance than to execute the plain select statement
since the parameters are hold in the derived class TableDataSet
>3.3) IMHO TableDataSet.fetchRecords() could implement the functionality on its own using
a prepared statement (aka copy/paste from the base class)
>3.4) It would be a rather small change - definitely less work than dumping Village as
proposed by Henning Schmiedehausen ... ;-)
>4) I can't say if this solution has any unwanted side effects on existing TORQUE installations
- is there a regression test available similiar to OJB?!
>5) I also don't know if I'm looking at an obsolete problem or at a problem where a simple
workaround exists. I went through the mailing lists but I'm not a TORQUE and/or ORACLE guru
hence the posting to both mailing lists.
>6) Are there any databases which go belly up using tons of prepared statements?! Wouldn't
make much sense to crash all the other databases just to fix an Oracle issue. A hardcore solution
would be checking the class name of the database connection if it could be a Oracle database
being used ... but even thinking about it hurts.
>Thanks in advance,
>Siegfried Goeschl

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message