Village API: Doing unprepared SELECT before UPDATE and how to fix it

["Göschl,Siegfried" <Si...@drei.com>]

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

Re: Village API: Doing unprepared SELECT before UPDATE and how to fix it

[Scott Eade <se...@backstagetech.com.au>]

Instructions for accessing the Village source are at:

    http://share.whichever.com/index.php?SCREEN=village

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

Scott

-- 
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au


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