Objection to deprecate lockTable was: Missing close-operations for Statements

[Michael Beier <mb...@VPS.DE>]

Hello Thomas, 
I must say, that i do have objections, as we currently use this method.
Im not quite sure, but i think, the ID-Generator uses these methods too, as the Statement implicates (SELECT next_id FROM); the tablerow next_id is only inside the ID-Table.
This is a bug, which i stated before, but no one seems to have noticed.
some of the adapters have the false logic (next_id instead of *) in there sourcecode, so that you can not use this function in general. i changed that localy in my torque code, and we do use this method for locking tables in general.

If this Function will be deleted, wich other way will be there to lock a table if not using a DB-Specific PS ?
This would bring torque a step away from making the javacode independent to the sql-code.

Michael Beier
 

vps Video Print Systeme GmbH 
Dipl.-Inf. Michael Beier

-----Ursprüngliche Nachricht-----
Von: Thomas Fischer [mailto:fischer@seitenbau.net]
Gesendet: Freitag, 18. März 2005 11:22
An: Apache Torque Developers List
Betreff: RE: Missing close-operations for Statements






Hendrik,

I cannot imagine a reason why the statement should not be closed. However,
I have looked for references to the lockTable code and found none. So I do
not think this is the cause for your problem.

I have tested that the runtimetest on oracle works without the lockTable
and unlockTable methods in DB.java and the respective adapter (Oracle, in
my case).
I would like to deprecate the methods from the adapter and mark them as
being deleted in a future release. Does anybody have any objections to that
?

    Thomas



Hendrik Busch <he...@lexisnexis.de> schrieb am 18.03.2005 10:23:42:

> Hi!
>
> We are currently porting major pieces of our software from MySQL to
> Oracle. I'm currently stuck with the Oracle "too many open cursors"
> failure. Having checked our own software first I have checked the Torque
> sources next.
> The most notable thing I found when searching for unclosed
> JDBC-resources were the missing close()-calla to the Statements used in
> the many DB adapters, including the Oracle adapter. Most methods look
> like this:
>
> public void lockTable(Connection con, String table) throws SQLException
> {
>    Statement statement = con.createStatement();
>
>          StringBuffer stmt = new StringBuffer();
>          stmt.append("SELECT next_id FROM ")
>                  .append(table)
>                  .append(" FOR UPDATE");
>
>          statement.executeQuery(stmt.toString());
> }
>
> The used statement does remain open. Was this done on purpose with an
> intention I don't see or did someone simply forget to close the
> Statements? Since we are performing database operations with a very high
> rate, those things sometimes tend to cause problems.
>
> --
> Mit freundlichen Grüßen / Kind regards
>
> Hendrik Busch - Senior Developer
>
> LexisNexis Deutschland GmbH
> http://www.lexisnexis.de
> Feldstiege 100
> D-48161 Münster
> phone +49 (0) 2533-9300-455
> fax +49 (0) 02533-9300-50
> hendrik.busch@lexisnexis.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>


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


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

RE: Objection to deprecate lockTable was: Missing close-operations for Statements

[Thomas Fischer <fi...@seitenbau.net>]

Hi Michael,

Other people have already objected, and I have realized that it is not a
good idea and refrained from it.

The reason why I originally considered to remove the methods is the
following: Although this method suggest that there is a way to lock and
unlock tables in a database independent way, in fact there isn't. For
example in oracle, it seems that a lock can only be released by issuing a
commit, which has other side effects. So I do not think this will help much
in making code database independent.

What the methods do aqchieve is that if locking and unlocking works, you do
not have to do it via SQL, which is (from Torque's view) also a good thing.

(Another point which led me to that suggestion was that I thought that
everything which you can do by locking tables can also be done by
serializable transactions.  I realized in the meantime that I was wrong.)

If you have code to improve the adaptors and have not already done so, can
you please open a scarab issue (http://issues.apache.org/scarab/issues).
Request a role as observer (replace the localhost:somePort part in the
"confirm registration email" by issues.apache.org), create a new issue,
upload your patches as unified diffs. AFTER you have uploaded all patches,
save the issue.
If there already exists a scarab issue, can you please mail the issue Id.

   Thanks,

       Thomas

"Michael Beier" <mb...@VPS.DE> schrieb am 31.03.2005 14:04:39:

> Hello Thomas,
> I must say, that i do have objections, as we currently use this method.
> Im not quite sure, but i think, the ID-Generator uses these methods
> too, as the Statement implicates (SELECT next_id FROM); the tablerow
> next_id is only inside the ID-Table.
> This is a bug, which i stated before, but no one seems to have noticed.
> some of the adapters have the false logic (next_id instead of *) in
> there sourcecode, so that you can not use this function in general.
> i changed that localy in my torque code, and we do use this method
> for locking tables in general.
>
> If this Function will be deleted, wich other way will be there to
> lock a table if not using a DB-Specific PS ?
> This would bring torque a step away from making the javacode
> independent to the sql-code.
>
> Michael Beier
>
>
> vps Video Print Systeme GmbH
> Dipl.-Inf. Michael Beier
>


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